TA貢獻1812條經驗 獲得超5個贊
到目前為止我所看到的摘要：
有些人根本不喜歡級聯。
當關系的語義可能涉及排他性的“是 ”描述的一部分時，級聯刪除可能很有意義。例如，OrderLine記錄是其父訂單的一部分，并且OrderLines永遠不會在多個訂單之間共享。如果Order消失，OrderLine也應該消失，沒有Order的行將成為問題。
級聯刪除的典型示例是SomeObject和SomeObjectItems，在這種情況下，沒有相應的主記錄就不會存在項目記錄。
你應該不使用級聯刪除，如果你保存歷史或使用“軟/邏輯刪除”，您只設置一個刪除位列1 /真。
當您在表之間使用實鍵而不是代理鍵（標識/自動增量列）時，級聯更新可能會很有意義。
當您具有可變的外鍵（例如可以更改的用戶名）時，Cascade Update的典型示例。
你應該不使用級聯更新與被標識/自動增量列鍵。
級聯更新最好與唯一約束結合使用。
您可能希望在允許操作進行級聯之前從用戶那里獲得額外的確認，但這取決于您的應用程序。
如果您錯誤地設置了外鍵，級聯會給您帶來麻煩。但是，如果您做對的話，您應該可以。
在完全理解之前，使用級聯是不明智的。但是，它是一個有用的功能，因此值得花一些時間來理解。
TA貢獻1828條經驗 獲得超13個贊
外鍵是確保數據庫引用完整性的最佳方法。避免由于魔術而導致的級聯就像在匯編中編寫所有內容一樣，因為您不相信編譯器背后的魔術。
不好的是錯誤使用了外鍵，例如，向后創建外鍵。
胡安·曼努埃爾（Juan Manuel）的例子就是規范的例子，如果您使用代碼，則有更多的機會在數據庫中留下偽造的DocumentItem，這些東西會咬你。
級聯更新很有用，例如，當您通過可以更改的內容引用數據時，例如說用戶表的主鍵是名稱，姓氏組合。然后，您希望該組合中的更改傳播到引用的任何位置。
@Aidan，您所指的這種清晰度付出了高昂的代價，即有可能將虛假數據保留在數據庫中，這是不小的機會。對我而言，通常只是缺乏對DB的熟悉，并且在與DB合作之前無法找到哪些FK會加劇這種恐懼。要么，要么是不斷地濫用級聯，在實體在概念上不相關的地方，或者必須保留歷史的地方使用級聯。
TA貢獻1836條經驗 獲得超3個贊
我從不使用級聯刪除。
如果我想從數據庫中刪除某些內容，我想明確地告訴數據庫我要取出的內容。
當然，它們是數據庫中可用的功能，有時可能可以使用它們，例如，如果您有一個“ order”表和一個“ orderItem”表，則您可能希望在刪除某個表時清除它們。訂購。
我喜歡從代碼（或存儲過程）中獲得的清晰度，而不是發生“魔術”事件。
出于同樣的原因，我也不喜歡觸發器。
需要注意的是，即使您刪除了一個“訂單”，即使級聯刪除刪除了50個“ orderItem”，您也會得到“ 1行受影響”的報告。
舉報