大家設計資料庫時是否使用外來鍵

回答一:

外來鍵是否採用看業務應用場景，以及開發成本的，大致列下什麼時候適合，什麼時候不適合使用：

1. 網際網路行業應用不推薦使用外來鍵：使用者量大，併發度高，為此資料庫伺服器很容易成為效能瓶頸，尤其受io能力限制，且不能輕易地水平擴充套件；若是把資料一致性的控制放到事務中，也即讓應用伺服器承擔此部分的壓力，而引用伺服器一般都是可以做到輕鬆地水平的伸縮；

2.傳統行業

1>.軟體應用的人數有限，換句話說是可控的；

2>.資料庫伺服器的資料量也一般不會超大，且活躍資料有限；

綜合上述2句話描述，也即資料庫伺服器的效能不是問題，所以不用過多考慮效能的問題；另外，使用外來鍵可以降低開發成本，借助資料庫產品自身的觸發器可以實現表與關聯表之間的資料一致性和更新；最後一點，使用外來鍵的方式，還可以做到開發人員和資料庫設計人員的分工，可以為程式設計師承擔更多的工作量；

為何說外來鍵有效能問題：

1.資料庫需要維護外來鍵的內部管理；

2.外來鍵等於把資料的一致性事務實現，全部交給資料庫伺服器完成；

3.有了外來鍵，當做一些涉及外來鍵字段的增，刪，更新操作之後，需要觸發相關操作去檢查，而不得不消耗資源；

4.外來鍵還會因為需要請求對其他表內部加鎖而容易出現死鎖情況；

回答二:

我想，這取決於資料庫的用途、規模、架構，有外來鍵，可以提高魯棒性、健壯性，但是約束檢驗顯然會拖慢速度。

規模上說，資料量大的不適合用外來鍵，小的可以用；用途上安全性、可靠性很重要的就要用外來鍵，否則可以不用。具體情況具體解決了，因為也有矛盾的時候，資料量極大，但是又要求高可靠，例如銀行金融、晶元生產等，仍然需要外來鍵的存在。可以通過san+raid等硬體提公升解決矛盾。

要求高併發的情況下，並不適合外來鍵，有的連關聯式資料庫都不用了，甚至資料庫都不用了。

這類問題真沒有絕對的答案，什麼情況下該怎樣做，只能是多想，多做了，錯的多了，就懂了