PHPz2017-04-17 16:10:22
外鍵是約束,既然是約束肯定就會增加額外的開銷。例如書中常見的範例,學生選課系統,學生表和課程表,中間一定會有一個學生課程關聯表。如果新增了外鍵約束,你在刪除某個課程的時候,一定會先檢查這個課程是不是有學生已經選了,不然你刪除後學生選的那個課程會找不到而引發錯誤。
不明白為什麼要反模式,省略外鍵約束能使得資料庫設計更加簡單、靈活,或者執行更加高效,但你還是不得不在其他方面付出相應的代價,必須增加額外的程式碼來手動維護引用完整性。本來資料庫一個約束鍵可以解決的,現在還要寫一段程式碼去維護。而且手動寫程式碼維護判斷,也是一種約束,也會有效能損耗,只不過是在邏輯層面,和資料庫相比不會快到哪去吧。
伊谢尔伦2017-04-17 16:10:22
外鍵和例如範式這種東西只應該存在於教科書上面。禁止外鍵和反範式才是應該做的。外鍵和查詢效率並沒有連結。作用只是建立資料的聯繫,那麼,為何資料的聯繫為何不透過邏輯來約束呢。
PHPz2017-04-17 16:10:22
工作以來從來沒加過外鍵 :D 依賴多了反而麻煩,性能的話應該沒影響吧,從來沒看見過添加外鍵來提升效率的文檔。 我是菜鳥,別噴我,哈哈,傷不起。路過路過
大家讲道理2017-04-17 16:10:22
外健主要是保持資料的完整性和一致性。譬如用戶表和用戶訂單表,如果沒有外健關聯,你是可以插入訂單表的。但是這個訂單表屬於那個用戶,你怎麼知道。那這樣的數據就變成孤魂野鬼了。有了外健關聯。你在插入的時候必須要求用戶表中有相關用戶才能插入,同里你在刪除用戶表的資料時,如果訂單表有引用的話,你是無法刪除的。這就保證了資料的一致性和完整性。
大家讲道理2017-04-17 16:10:22
外鍵約束主要是在資料庫層面保證資料的一致性,對效能提升沒什麼幫助,因為插入和更新資料需要檢查外鍵,理論上效能會有所下降,在oralce中外鍵會增加主從表中主表鎖定的競爭,對效能是負面的影響。
實際的項目,不建議使用外鍵,一方面是降低開發的複雜度(有外鍵的話主從表類的操作必須先操作主表),另外是有外鍵在處理數據的時候非常麻煩。
在應用層面做資料的一致性檢查,本來就是一個正常的功能需求,如學生選課的場景,課程肯定不是輸入的,而是透過下拉或查找等方式從系統中進行選取,就能夠保證是合法的課程ID,因此就不需要靠資料庫的外鍵來檢查了。