資料庫設計之外鍵的思考，資料庫設計思考

資料庫設計之外鍵的思考，資料庫設計思考

    關於是否使用外鍵在業界也沒有統一的標準，大家爭論的焦點是資料一致性和效能上。

    支援使用外鍵方，強調如果不使用外鍵，資料一致性無法保證，效能消耗可以忽略。

    反對使用外鍵方，資料一致性可以通過程式保證，效能有大問題，資料維護很麻煩，如果是大系統，整個外鍵的關係就像編製的一張大網。再者開發人員很難真正用好外鍵。

    其實兩種觀點我都支援，現狀是我基本沒用過外鍵。沒使用外鍵會出現什麼問題呢？

    1.資料一致性無法保證。出現這種情況最多的情況是，如A表示基礎資料表，它被很多模組引用，B表是業務表，A表中刪除了資料，B表的資料關聯A的資訊沒有刪除，導致寫SQL時會出現大量的外串連。

    2.從表上沒有建索引。如果從表上有外鍵，這種情況悲劇就要發生了。請看參考我之前寫的 外鍵不加索引引起的效能問題

    3.使用外鍵在後台修改資料非常麻煩，當然這個不是外鍵的問題，只是系統自身的問題。

   你看任何一本涉及到資料庫設計的書籍，都會告訴你一定要使用外鍵，但理想和實現總是有點差距，如何選擇，我的建議：

    1.如果你對資料一致性要求非常高，關乎人命，錢，一定要加外鍵，像財務系統等。反之，可以犧牲一下，換取方便。

    2.如果不加外鍵，基礎的表（就是會被引用的表）要做邏輯刪除（加一個刪除的標識位），可以避免大量的外串連。

    3.不管是否加外鍵，一定要索引。

資料庫設計外部索引鍵關聯

保持資料一致性，完整性，主要目的是控制儲存在外鍵表中的資料。 使兩張表形成關聯，外鍵只能引用外表中的列的值！
如果沒有的話，萬你的資料出現了不一致，你也不會有所發現
 
資料庫中外鍵的作用是神馬？為何我看到很多mysql的資料庫設計都不用外鍵的?

比如你有兩張表：A表和B表把A的主鍵放到B中就叫B的外鍵，作用，一般用於多表聯查，通俗的說就是讓兩張表產生聯絡。沒用過mysql但道理都是一樣的。需要聯絡就的有主鍵和外鍵，不需要自然沒有，