淺析關聯設計
【范式】
比較理想的情況下，數據庫中的任何一個表都會對應到現實生活中的一個對象，如球員是一個對象，球隊是一個對象，賽程是一個對象，比賽結果又是一個對象等等，則就是范式。
【關聯設計】
對於關聯設計可以理解成表和表之間要有關聯關系，在對表查詢時經常使用關聯查詢。
補充：關系數據庫的來源：對一個事務操作要從多個表中讀。
如2014巴西世界杯這個表空間中要有球員表、賽程表、比賽結果表，比賽結果表要關聯比賽的隊伍名字、球員的名字最後關聯一個比賽的結果，這就是一個簡單的關聯關系。至於為何要設計成范式，也很好理解，這是為了不冗余存儲數據，同一場比賽的結果就不用重復的存儲了，如巴西對德國0:0和德國隊巴西也為0:0（因為是同樣的兩支隊伍，結果必然是一樣的），這樣就可以只存在一行數據了，結果也就是保持了數據的獨立性。
【不良好的范式、關聯設計舉例】
如果不良好的范式、關聯設計會引發關聯的成本的問題，舉個例子，如果兩張表的成本都很大，來做等值連接和不等值連接時將會有很大的成本問題。如從世界杯的進球球員中去關聯到該名球員在俱樂部中一個賽季的表現情況時，如進球數、犯規數、搶斷數等等一些列數據時，而這個數據是存在於一個較大的表中的，對於這兩張表的關聯成本將會很大。因為世界杯中進球球員的一行記錄有可能對應賽季表中的很多行數據，而每一個球員都是這樣，第一個表中的一行數據對應於第二個表中的很多行數據，這種交叉的鏈接過程中，成本是相當高的。這也就引出了，目標比較流行的技術趨勢，反范式。
【反范式】
反范式，打破舊有的良好設計，而故意使用存在冗余的數據。
舉個例子，如下圖
表1：
FIFA球員ID
球員名
國籍
2014世界杯進球
......
10982
小羅
葡萄牙
6
......
23781
比利亞
西班牙
5
......
12312
穆勒
德國
4
......
......萬條
表2
FIFA球員ID
10982
23781
12312
......
地區
歐洲
歐洲
歐洲
......
俱樂部
皇家馬德裡
馬德裡競技
拜仁慕尼黑
......
2014賽季進球
32
28
6
......
......萬條
如上，表1是世界杯球員統計數據，表2為球員在俱樂部中的表現情況。為了避免球員重名情況，表2使用了ID號作為標識。現在想要查看世界杯表現優異有進球的小羅在俱樂部的表現情況，即要關聯世界杯有進球的球員在俱樂部中的表現情況時，要通過第一張表進行關聯，先要知道小羅的ID號，再查到對應的俱樂部表現情況。表1中的一行數據要對應到表2中的1列數據，表2中的1列數據也要對應表1中的1行數據，在以萬條計的兩張大表中，這個關聯成本是相當高的。雖然兩張表符合了良好的范式、關聯性，防止了冗余、防止了沖突，但在性能上就非常差了。對應的改善做法就是不寫ID號，而是直接填寫球員的名字，如果有重名在後台數據庫做一個標識。這樣想查詢某球員俱樂部表現情況時，就直接到表2中去查詢相應的數據信息即可。從設計上出發，沒有一個好的范式、沒有一個好的關聯設計。但從性能上分析，比一個良好的范式、關聯設計體現了更好的性能。
