外鍵的使用,跟他的優缺點


轉自:http://www.cnblogs.com/fuland/p/4280434.html

主鍵和索引是不可少的,不僅可以優化數據檢索速度,開發人員還省不其它的工作,

矛盾焦點:數據庫設計是否需要外鍵。這里有兩個問題:一個是如何保證數據庫數據的完整性和一致性;二是第一條對性能的影響。

正方觀點:
1,由數據庫自身保證數據一致性,完整性,更可靠,因為程序很難100%保證數據的完整性,而用外鍵即使在數據庫服務器當機或者出現其他問題的時候,也能夠最大限度的保證數據的一致性和完整性。
eg:數據庫和應用是一對多的關系,A應用會維護他那部分數據的完整性,系統一變大時,增加了B應用,A和B兩個應用也許是不同的開發團隊來做的。他們如何協調保證數據的完整性,而且一年以后如果又增加了C應用呢?
2,有主外鍵的數據庫設計可以增加ER圖的可讀性,這點在數據庫設計時非常重要。
3,外鍵在一定程度上說明的業務邏輯,會使設計周到具體全面。

反方觀點:
1,可以用觸發器或應用程序保證數據的完整性
2,過分強調或者說使用主鍵/外鍵會平添開發難度,導致表過多等問題
3,不用外鍵時數據管理簡單,操作方便,性能高(導入導出等操作,在insert,   update,   delete   數據的時候更快)
eg:在海量的數據庫中想都不要去想外鍵,試想,一個程序每天要insert數百萬條記錄,當存在外鍵約束的時候,每次要去掃描此記錄是否合格,一般還不 止一個字段有外鍵,這樣掃描的數量是成級數的增長!我的一個程序入庫在3個小時做完,如果加上外鍵,需要28個小時!  

結論:
1,在大型系統中(性能要求不高,安全要求高),使用外鍵;在大型系統中(性能要求高,安全自己控制),不用外鍵;小系統隨便,最好用外鍵。
2,用外鍵要適當,不能過分追求
3,不用外鍵而用程序控制數據一致性和完整性時,應該寫一層來保證,然后個個應用通過這個層來訪問數據庫。

需要注意的是:MySQL允許使用外鍵,但是為了完整性檢驗的目的,在除了InnoDB表類型之外的所有表類型中都忽略了這個功能。這可能有些怪異,實際上卻非常正常:對於數據庫的所有外鍵的每次插入、更新和刪除后,進行完整性檢查是一個耗費時間和資源的過程,它可能影響性能,特別是當處理復雜的或者是纏繞的連接樹時。因而,用戶可以在表的基礎上,選擇適合於特定需求的最好結合。所以,如果需要更好的性能,並且不需要完整性檢查,可以選擇使用MyISAM表類型,如果想要在MySQL中根據參照完整性來建立表並且希望在此基礎上保持良好的性能,最好選擇表結構為innoDB類型


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM