關係的真相
長期以來，我們習慣了稱關係型資料庫中的表為二維表。因為它有行和列，很容易我們就可以把它同乙個二維平面聯絡起來，但事實上，這並非關係型資料庫的初衷，也並非符合關係模型的設計。其實長久以來，我對此也只有乙個很模糊的概念，對平面表的觀點雖有懷疑，卻一直無從驗證。直到有一天，翻出一本老書——《關聯式資料庫》（石樹剛、鄭振楣編著，清華大學出版社，2023年），這本老書沒有什麼流行的新噱頭，卻滿滿當當地淨是數學理論。這本書讀起來並不是很誘人，不過的確很嚴謹，澄清了我的很多不明之處。也激勵我找來各種權威材料重頭學起。薄薄一本書，定價只有9.9元，想想這應當是我在上學時，從舊書攤上買的，可能當時只花了不到五元錢。這肯定是我買的價效比最高的一本書了。
在此，我不想從別人書中抄出大段原話，拼出一篇文字，有這工夫還不如上網回貼子更有成就感，我寧願將我的心得，用並不嚴密，但盡可能易懂的語言寫下。讓朋友們先對關係模型有個基本概念，使眾多像我這樣非科班出身的讀者多少了解一下事實真相，不至於在工作中有所不便。如果你想真正掌握關係型資料庫的數學模型，請讀一讀這本不流行的老書《關聯式資料庫》。當然，還有很多新近的正規教材也寫得很不錯，比如現在在我手邊的《database system concepts》（機械工業出版社）和《sql-3 參考大全》（機械工業出版社）。前兩本寫得更嚴謹一些，後一本是譯得不太好，有些關鍵地方讀著莫名其妙，不過總得來說還是本難得的好書。
言歸正傳，現在我們說說關係型資料庫到底是怎麼一回事。我們先看乙個表：
x y z
------------------
0 0 0
1 1 1
0 0 1
0 1 1
……這個表儲存乙個三維空間內的一些點。我們可以很清楚地看到，每乙個完整的行，才代表乙個點。僅定位某行某列，它並不能表達這個表所定義的資訊結構。當我們向這個表中插入或刪除資料，它仍代表三維空間內的點集。但如果我們增加一列t（time)呢？那一切全變了，它不再是三維空間了，現在，這個表中儲存的是四維的資訊了（讀過相對論的朋友應當了解，相對論中的時空就是乙個四維座標系）。刪除一列呢？比如z列，現在我們面對的就是x-y 平面了，這是乙個二維座標系。也就是說，在表中刪除或增加或修改若干列，並不會改變這個表所代表的意義。而修改或增刪列，就會改變表的結構，表所代表的意義也就不同於以前了。表的行和列，並不是平等的！我們不能簡單地把它理解為乙個平面！相反，我認為，將表的結構理解為乙個代數空間更合適，這樣，表中的每一行是這個代數空間中的乙個點，那麼當前表中的資訊就形成了這個空間中的乙個點集。當然，這個集合還可有其它的約束條件，下面我們從關係模型說起。
在嚴格意義上的關係模型中，乙個關係模式，包括關係名、有限屬性集、屬性值域、屬性列到值域的對映、完整性約束和屬性間依賴。對應資料庫中的結構，通常乙個關係模式對應乙個或多個表和檢視。這些表和檢視有其各自包括的列，而列有列名、列的資料型別、表和檢視的主鍵約束、外來鍵約束、檢查、斷言、觸發器（在sql server2000中，已可以在檢視中定義索引和觸發器，再加上檢視本身的 sql指令碼，檢視以可以定義為乙個完整的關係模式）。乙個簡單的關係模式可以只由乙個表構成，而多個元組（表或檢視）組成的關係，其相互的關聯由外來鍵和觸發器來完成。在這個定義中，關係中的各個列（也就是說關係的模式）可以有很強的依賴性。比如某些列有主鍵約束，另一些列有引用外來鍵。而行與行之間（也就是說關係之間）的依賴只存在於兩種情況——外來鍵和觸發器。其中外來鍵可以表達為模式上的（也就是列之間的）依賴。例如以下訂單系統，它由客戶表，訂單表和
create table customers(
customerid int not null,
firstname char(20),
lastname char(20),
city varchar(30),
constraint pk_customer primary key(customerid)
)create table goods(
id int not null,
name char(20) not null,
number int,
price money,
constraint pk_good primary key(id))
create table orders(
orderid int not null,
customerid int not null,
orderdate datetime,
constraint pk_order primary key(orderid),
constraint fk_customer foreign key (customerid)
references customers(customerid))
create table items(
itemsid int not null,
orderid int not null,
number int not null
constraint pk_item primary key(itemsid),
constraint fk_good foreign key (itemsid)
references goods(id),
constraint fk_order foreign key (orderid)
references orders(orderid)
)以上一表中，一位客戶可以有多張訂單，訂單的訂戶依賴客戶表。一張訂單可以有多個條目，明細條目又依賴於訂單和商品的存在。這四個表就構成乙個關係模式，四個表都有其主鍵，表中的其它列依賴於主鍵列。表之間的外來鍵引用則構成了表之間的依賴關係。由此聯接起了整個模式。每乙個完整的訂單，包括orders表中的訂購資訊和items表中的明細，形成乙個關係。而乙個使用者和他的訂單，又可以形成一種新的關係，這些關係的模式，可以由sql語句來表達，這裡不詳細講了，朋友們可以試一下，很簡單的聯接查詢而已。我們可以看到，這個典型的關係中，資訊的內容之複雜，遠遠超出了「幾個二維平面表」所能定義的。「帶有強約束條件關聯的若干代數空間點集」可能更好一些。甚至，我們還可以在其上定義更強的約束，比如用乙個觸發器保證使用者的訂購數在某一範圍內。當我們增刪訂單，存貨甚至客戶時，由於強有力的約束存在，保證了每個關係仍是完整的。可列的定義本身就是關係模式的一部分，如果我們改變或增刪了列，修改的是整個模式。至少乙個代數空間，被我們改變了。這也就是行和列的區別。當然，只定義乙個表，不給它加以任何約束，在技術上是允許的，但這樣的表不能稱為乙個關係。它甚至不能保證最基本的關係完整性。如以前的文章所示，這樣的表輕易就可以插入重複資料，而這些不能互相區別的資料並不能給我們更多的資訊。這種沒有約束的表在實用中應當嚴格限制於臨時表，不應在其它任何場合出現。
希望讀了這篇文章的朋友，能夠不再犯我當初常初的錯誤，建立乙個又乙個沒有任何約束的表，存入不可靠的資料。我們應當把資訊的結構和關係模型直接表達在資料庫的設計中，這才是關係型資料庫的意義所在。這一次幾乎沒有可執行的**，可能讀者們會有意見。不過真心祝大家能理解我的意思，在關係型資料庫的世界中更輕鬆自如地工作。如果您有批評、表揚、指導，我在這裡專心地聽取，謝謝您的支援。我在書中專注於sql server 和interbase，希望有oracle或db2等其它資料庫系統的高手與我合作，完成本書的不同版本內容，與我分享勞動的艱辛和成功的喜悅。
SQLStory摘錄（五） 關係真相
長期以來，我們習慣了稱關係型中的表為二維表。因為它有行和列，很容易我們就可以把它同乙個二維平面聯絡起來，但事實上，這並非關係型資料庫的初衷，也並非符合關係模型的。其實長久以來，我對此也只有乙個很模糊的概念，對平面表的觀點雖有懷疑，卻一直無從驗證。直到有一天，翻出一本老書 關聯式資料庫 石樹剛 鄭振楣...
sqli labs系列 第五關
更改id後無果，不能用union聯合查詢 此處用報錯注入 報錯注入的概念 1 通過floor報錯 and select 1 from select count concat payload floor rand 0 2 x from information schema.tables group b...
sqli labs系列 第五關
更改id後無果，不能用union聯合查詢 此處用報錯注入 報錯注入的概念 1 通過floor報錯 and select 1 from select count concat payload floor rand 0 2 x from information schema.tables group b...