關於是否使用外來鍵在業界也沒有統一的標準，大家爭論的焦點是資料一致性和效能上。
支援使用外來鍵方，強調如果不使用外來鍵，資料一致性無法保證，效能消耗可以忽略。
反對使用外來鍵方，資料一致性可以通過程式保證，效能有大問題，資料維護很麻煩，如果是大系統，整個外來鍵的關係就像編制的一張大網。再者開發人員很難真正用好外來鍵。
其實兩種觀點我都支援，現狀是我基本沒用過外來鍵。沒使用外來鍵會出現什麼問題呢？
1.資料一致性無法保證。出現這種情況最多的情況是，如a表示基礎表，它被很多模組引用，b表是業務表，a表中刪除了資料，b表的資料關聯a的資訊沒有刪除，導致寫sql時會出現大量的外連線。
2.從表上沒有建索引。如果從表上有外來鍵，這種情況悲劇就要發生了。請看參考我之前寫的外來鍵不加索引引起的效能問題
3.使用外來鍵在後台修改資料非常麻煩，當然這個不是外來鍵的問題，只是系統自身的問題。
你看任何一本涉及到資料庫設計的書籍，都會告訴你一定要使用外來鍵，但理想和實現總是有點差距，如何選擇，我的建議：
1.如果你對資料一致性要求非常高，關乎人命，錢，一定要加外來鍵，像財務系統等。反之，可以犧牲一下，換取方便。
2.如果不加外來鍵，基礎的表（就是會被引用的表）要做邏輯刪除（加乙個刪除的標識位），可以避免大量的外連線。
3.不管是否加外來鍵，一定要索引。
MySQL資料庫學習二 之 外來鍵約束
回顧總結 1 約束 分為表級約束和列級約束 2 非空約束，主鍵約束，預設約束，唯一約束 新 1 外來鍵約束 1 父表和子表使用相同的儲存引擎，禁止使用臨時表 2 儲存引擎必須是innodb 3 外來鍵列和參照列必須有相似的資料型別，數字的長度和有無符號必須相同，字元的長度可以不同。3 外來鍵列和參照...
ORACLE同步資料庫 之外鍵生成指令碼
在實際工作中，往往出現從測試環境到正式環境的資料庫同步。由於，同步是間隔執行。如果又對資料庫操作，記錄不充分。這時候，可以根據oracle字典表，自動生成執行檔案指令碼。select alter table cc.table name add constraint cc.constraint nam...
資料庫設計外來鍵
今天心情很煩躁，公司來了新員工，我感覺到自己這個渣渣要晚年不保啊，隨後就隨便網上逛逛，看到這個挺有意思。設計外來鍵竟然還有人不會？哈哈哈，這不是說我呢嘛！外來鍵一般用於一對多的時候，比如說某個型別type下面可能有多個物件。訂單的話，乙個訂單號肯定會有關於這個訂單 號碼 的訂單詳情，這是給客戶看的，...