外鍵在電商網站資料庫設計中用的多不多啊？

外鍵在電商網站資料庫設計中用的多不多啊？

比如用在一些關聯表上，感覺很實用，保證了不會產生錯誤的資料行，和無用的資料行，但是也有人說盡量不要去使用外鍵，在程式中控制資料的完整性條件約束性就可以了，否則不方便維護，我也不知道到底怎麼樣好。

回複內容：

外鍵在電商網站資料庫設計中用的多不多啊？

比如用在一些關聯表上，感覺很實用，保證了不會產生錯誤的資料行，和無用的資料行，但是也有人說盡量不要去使用外鍵，在程式中控制資料的完整性條件約束性就可以了，否則不方便維護，我也不知道到底怎麼樣好。

但是也有人說盡量不要去使用外鍵，在程式中控制資料的完整性條件約束性就可以了，否則不方便維護
你要看是什麼人說的。
很多程式員的資料庫水平比不上使用者。這些人認為程式是萬能的。
很多DBA認為資料是最重要的，比程式活的長。程式不能用了，資料仍是企業的重要資產。

如果不用外鍵，資料的完整性得不到保證。如果你覺得這樣可以接受，當然可以不用外鍵。
外鍵是基本的資料庫約束，如果這都省略了，那你的資料庫根本不能稱為資料庫。很多人說關聯式資料庫效能差，其實大部分都是他們設計得差。

下面談談很多人所說的外鍵的缺點。
外鍵會帶來不便

1. 比如，刪一條資料出錯
   我覺得這不是壞事，尤其是對使用者來說。想想編程時，編譯器也會報錯，我們都知道這不是壞事，反而提前防止了錯誤。

2. 又比如，批量insert
   如果你可以肯定資料沒問題，DBMS提供了忽略外鍵約束的選擇。但是，當資料的輸入來源不可靠時，很容易出現資料不一致，所以大部分時間外鍵（還有其他約束）是必要的。

外鍵需要額外的開銷，降低效能
任何代碼都有開銷，關鍵看值不值得。什麼事都不做，是最快的，根本不需要花時間。
正因為資料的正確性是至關重要的，用外鍵當然值得。

即使不用外鍵，你也要在程式中控制資料的正確性。所以這個開銷是必須的，不能省掉的。
通過程式控制資料完整性有很多缺點，比如
1 程式bug
基本上沒有無bug的程式，這就是說，外鍵的功能無法可靠地被程式替代。

2 資料和程式的強耦合
資料庫只能被一個程式使用，要支援多個程式，並且保證資料完整性，
a) 要麼重複邏輯
每個程式自己控制資料的一致性，顯然是很糟糕的。
b) 要麼通過共同的介面訪問資料庫
這是比較流行的一種方法。3層架構，SOA，...
我不敢說這些架構都是錯誤的，他們都有特定的用途。但是你要明白，一個系統越複雜，零件越多，出錯的可能性就越大，而且效能也越差。

總而言之，如果你認為資料正確性是必須要保證的，那麼你就必須付出一定的代價來實現。用外鍵比用程式控制更可靠，同時更簡單直接，減輕了程式的負擔。
DBMS有40年的曆史，是頂尖的程式員用C/C++開發出來的，經過重重測試，被無數項目用到，其可靠性和效能已經接近最優狀態了。
你如果覺得你們項目裡的程式員能做得更好，對事務、並發等技術都無比熟悉，又有充足的時間，那你們可以用程式控制。

老實說，我接觸的項目很多都是不用外鍵約束的，很多都是不考慮正常化設計的。這樣的系統很複雜（沒必要這麼複雜），效能不好。這是我的切身體會。

當然，所有事情都不能一概而論，不用外鍵的程式也能做得很好，賣得很好。當你做決定時，要想清楚後果。
我個人傾向於經典的方法，可靠的方法。

外鍵能保證資料的完整性和一致性,舉例說:
一個商品訂單表,訂單詳情表,訂單詳情表的訂單id依賴於訂單表的id,
學生表,學產生績表,成績表中的學號依賴於學生表中的主鍵。

換言之,要訂單詳情表中的訂單id要在訂單表存在才能插入,成績表中的學號要存在這個學號才能插入.

麻煩是當刪除學生時要相應刪除其有依賴關係的資料,

且mysql的myisam不支援外鍵,[設定了也無效]

看情況和偏好。有些外鍵可以放開，就比較靈活一點，放到程式裡頭去維護。

