對於主/外來鍵/索引來說，在一些開發團隊中被認為是處理資料庫關係的利器，也被某些開發團隊認為是處理某些具體業務的魔鬼，您的觀點呢？在實際應用中您會採取哪種方式？
矛盾焦點：資料庫設計是否需要外來鍵。這裡有兩個問題：乙個是如何保證資料庫資料的完整性和一致性；二是第一條對效能的影響。
正方觀點：
1，由資料庫自身保證資料一致性，完整性，更可靠，因為程式很難100％保證資料的完整性，而用外來鍵即使在資料庫伺服器當機或者出現其他問題的時候，也能夠最大限度的保證資料的一致性和完整性。eg：資料庫和應用是一對多的關係，ａ應用會維護他那部分資料的完整性，系統一變大時，增加了ｂ應用，ａ和ｂ兩個應用也許是不同的開發團隊來做的。他們如何協調保證資料的完整性，而且一年以後如果又增加了c應用呢？
2，有主外來鍵的資料庫設計可以增加er圖的可讀性，這點在資料庫設計時非常重要。
3，外來鍵在一定程度上說明的業務邏輯，會使設計周到具體全面。
反方觀點：
1，可以用觸發器或應用程式保證資料的完整性
2，過分強調或者說使用主鍵／外來鍵會平添開發難度，導致表過多等問題
3，不用外來鍵時資料管理簡單，操作方便，效能高（匯入匯出等操作，在insert, update, delete 資料的時候更快）eg:在海量的資料庫中想都不要去想外來鍵，試想，乙個程式每天要insert數百萬條記錄，當存在外來鍵約束的時候，每次要去掃瞄此記錄是否合格，一般還不止乙個欄位有外來鍵，這樣掃瞄的數量是成級數的增長！我的乙個程式入庫在3個小時做完，如果加上外來鍵，需要28個小時！
結論：1，在大型系統中（效能要求不高，安全要求高），使用外來鍵；在大型系統中（效能要求高，安全自己控制），不用外來鍵；小系統隨便，最好用外來鍵。2，用外來鍵要適當，不能過分追求3，不用外來鍵而用程式控制資料一致性和完整性時，應該寫一層來保證，然後個個應用通過這個層來訪問資料庫。
要不要顯示的建立外來鍵關聯？
示例 表a結構如下 uid name 1 張飛 2 呂布 表b結構如下 bid uid boss 1 2 曹操 2 1 劉備 外來鍵是保證資料庫一致性的重要手段，可以級聯更新 包括增刪改 當然可以不使用顯式的外來鍵，只需要每次做操作的時候 記得 同步更新相關的表資料即可。不過有了外來鍵，你如果忘記了...
資料庫要不要部署在docker容器內？
一 前言 近2年docker非常的火熱，各位開發者恨不得把所有的應用 軟體都部署在docker容器中，但是您確定也要把資料庫也部署的容器中嗎？目前為止將資料庫容器化是非常不合理的，但是容器化的優點相信各位開發者都嘗到了甜頭，希望隨著技術的發展能夠更加完美的解決方案出現。不要將資料儲存在容器中，這也是...
資料庫 外來鍵
外來鍵是什麼?外來鍵 fk 是用於建立和加強兩個表資料之間的鏈結的一列或多列。通過將儲存表中主鍵值的一列或多列新增到另乙個表中，可建立兩個表之間的鏈結。這個列就成為第二個表的外來鍵。外來鍵資料庫一級的完整性約束,由資料庫自行維護.你也可以手動建立.1如果存在外來鍵關係的話,任何修改主表主鍵欄位和刪除...