關於mysql中外部索引鍵關聯的一些個人理解

標籤：

      在我看來hibernate最麻煩的一件事就是配置外部索引鍵關聯，稍微不慎就會出現配置錯誤的情況，現在的項目全部都是在使用mybaits，而mybaits使用就簡單的多，起碼雖然說是要自己寫mysql語句，但是起碼這種做法在現階段的項目開發中還是非常的流行，以前經常聽到眼言論說用hibernate開發會比mybaits要來得快，其實那應該 是對於高手而言，但是絕大部分如我這群菜逼而言，老老實實的寫sql語句會更好一點，廢話不多說，今天主要是談談外部索引鍵關聯對在項目開發中的影響。

      表的關聯，在某種程度上來說只是一種邏輯概念，比如在我們開始項目之初，是需要進行表設計，在用diagram  designe這類工具r設計表的時候，難免不會有各重業務上的邏輯關聯的，這個時候如果你不使用外鍵管理，是很容易造成自身的邏輯混亂的，如果有那麼一根根線連著，我們就能追根溯本，搞清整個項目的流程結構。

     但是在物理結構的表上面，我們沒必要進行物理上的硬綁定，而我們期望的關聯，其實只是資料上存在的聯絡，而這種聯絡更多的是存在我們腦海裡，而非明面上，所以在進行業務代碼實現的時候，我們編寫程式的時候，只需要在程式中實現邏輯關連 的存取即可，但是如果我們非得加上什麼外部索引鍵關聯這層關係，只會帶來更多的資源消耗來進行所謂的一致性檢驗，資料完整性檢驗，其實有些時候我們並不需要這層檢驗和約束。

     我抽空問了幾個其他公司的朋友，在mysql的時候，很多地方都直接把外鍵跟直接刪除，當然這些都是互連網公司，因為相對於商務邏輯和速度，資料的完整性顯得並不那麼重要，各種的鎖表估計也是追求效能的我們所不能接受的，若是遇到各種高並發和大流量的情況，外鍵造成的死結和交易回復那直接只會讓程式猿罵娘。

    當然在比如說銀行或者是各種erp系統裡面，資料完整性比企業的命還重要的時候，通過程式去控制各種商務邏輯顯得並不那麼可靠，因為程式總是那麼容易攻破，而資料庫稍微要更難一點點，而且在銀行這種企業裡面，資料是絕不能夠輕易刪除，而非向我們這樣，如果哪些資料不盡人意，直接物理層面的給刪除掉。

    

 

關於mysql中外部索引鍵關聯的一些個人理解