資料庫設計到底要不要保留物理上的外來鍵
阿新 • • 發佈:2019-01-29
之前看過一些部落格,他們的爭議“資料庫設計要物理上的外來鍵,還是邏輯上外來鍵”。
議題焦點:
資料庫設計是否需要外來鍵。這裡有兩個問題:一個是如何保證資料庫資料的完整性和一致性;二是第一條對效能的影響。
正方觀點:
- 由資料庫自身保證資料一致性,完整性,更可靠,因為程式很難100%保證資料的完整性,而用外來鍵即使在資料庫伺服器當機或者出現其他問題的時候,也能夠最大限度的保證資料的一致性和完整性。
eg:資料庫和應用是一對多的關係,A應用會維護他那部分資料的完整性,系統一變大時,增加了B應用,A和B兩個應用也許是不同的開發團隊來做的。他們如何協調保證資料的完整性,而且一年以後如果又增加了C應用呢?
- 有主外來鍵的資料庫設計可以使ER圖儲存良好可讀性,這點在資料庫設計時非常重要。
- 外來鍵在一定程度上說明的業務邏輯,會使設計周到具體全面。
反方觀點:
- 可以用觸發器或應用程式保證資料的完整性
- 過分強調或者說使用主鍵/外來鍵會平添開發難度,導致表過多等問題
- 不用外來鍵時資料管理簡單,操作方便,效能高(匯入匯出等操作,在insert, update, delete 資料的時候更快)
。eg:在海量的資料庫中想都不要去想外來鍵,試想,一個程式每天要insert數百萬條記錄,當存在外來鍵約束的時候,每次要去掃描此記錄是否合格,一般還不 止一個欄位有外來鍵,這樣掃描的數量是成級數的增長!我的一個程式入庫在3個小時做完,如果加上外來鍵,需要28個小時!
結論:
- 在大型系統中(效能要求不高,安全要求高),使用外來鍵;在大型系統中(效能要求高,安全自己控制),不用外來鍵;小系統隨便,最好用外來鍵。
- 用外來鍵要適當,不能過分追求
- 不用外來鍵而用程式控制資料一致性和完整性時,應該寫一層來保證,然後個個應用通過這個層來訪問資料庫。