長期以來，我們習慣了稱關係型中的表為二維表。因為它有行和列，很容易我們就可以把它同乙個二維平面聯絡起來，但事實上，這並非關係型資料庫的初衷，也並非符合關係模型的。其實長久以來，我對此也只有乙個很模糊的概念，對平面表的觀點雖有懷疑，卻一直無從驗證。直到有一天，翻出一本老書——《關聯式資料庫》（石樹剛、鄭振楣編著，清華大學出版社，2023年），這本老書沒有什麼流行的新噱頭，卻滿滿當當地淨是數學理論。這本書讀起來並不是很誘人，不過的確很嚴謹，澄清了我的很多不明之處。也激勵我找來各種權威材料重頭學起。薄薄一本書，定價只有9.9元，想想這應當是我在上學時，從舊書攤上買的，可能當時只花了不到五元錢。這肯定是我買的價效比最高的一本書了。
這個表儲存乙個空間內的一些點。我們可以很清楚地看到，每乙個完整的行，才代表乙個點。僅定位某行某列，它並不能表達這個表所定義的資訊結構。當我們向這個表中插入或刪除資料，它仍代表三維空間內的點集。但如果我們增加一列t（time)呢？那一切全變了，它不再是三維空間了，現在，這個表中儲存的是四維的資訊了（讀過相對論的朋友應當了解，相對論中的時空就是乙個四維座標系）。刪除一列呢？比如z列，現在我們面對的就是x-y平面了，這是乙個二維座標系。也就是說，在表中刪除或增加或修改若干列，並不會改變這個表所代表的意義。而修改或增刪列，就會改變表的結構，表所代表的意義也就不同於以前了。表的行和列，並不是平等的！我們不能簡單地把它理解為乙個平面！相反，我認為，將表的結構理解為乙個代數空間更合適，這樣，表中的每一行是這個代數空間中的乙個點，那麼當前表中的資訊就形成了這個空間中的乙個點集。當然，這個集合還可有其它的約束條件，下面我們從關係模型說起。
在嚴格意義上的關係模型中，乙個關係模式，包括關係名、有限屬性集、屬性值域、屬性列到值域的對映、完整性約束和屬性間依賴。對應資料庫中的結構，通常乙個關係模式對應乙個或多個表和檢視。這些表和檢視有其各自包括的列，而列有列名、列的資料型別、表和檢視的主鍵約束、外來鍵約束、檢查、斷言、觸發器（在2000中，已可以在檢視中定義索引和觸發器，再加上檢視本身的sql指令碼，檢視以可以定義為乙個完整的關係模式）。乙個簡單的關係模式可以只由乙個表構成，而多個元組（表或檢視）組成的關係，其相互的關聯由外來鍵和觸發器來完成。在這個定義中，關係中的各個列（也就是說關係的模式）可以有很強的依賴性。比如某些列有主鍵約束，另一些列有引用外來鍵。而行與行之間（也就是說關係之間）的依賴只存在於兩種情況——外來鍵和觸發器。其中外來鍵可以表達為模式上的（也就是列之間的）依賴。例如以下訂單系統，它由客戶表，訂單表和
customeridintnotnull,1
《SQL Story》摘錄五 關係真相
關係的真相 長期以來，我們習慣了稱關係型資料庫中的表為二維表。因為它有行和列，很容易我們就可以把它同乙個二維平面聯絡起來，但事實上，這並非關係型資料庫的初衷，也並非符合關係模型的設計。其實長久以來，我對此也只有乙個很模糊的概念，對平面表的觀點雖有懷疑，卻一直無從驗證。直到有一天，翻出一本老書 關聯式...
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...