如果外鍵/級聯刪除不好，為什麼要使用具有該功能的數據庫伺服器？
我注意到 wordpress/rails 等不使用外鍵約束或級聯從數據庫中刪除功能。相反，他們在 PHP/Ruby/腳本級別處理這個！
我讀過這個和這個。大多數反對外鍵約束的論點都是關於性能、多執行緒、鎖定、可伸縮性等。
假設反對外鍵的論點是有效的，我的問題是：
- 如果外鍵不好，為什麼 WordPress/Rails/etc 使用支持外鍵的 sql-server？他們會從 MySQL 轉向 NoSQL 類型的伺服器中受益嗎？
- 另一方面，應用程序編碼的方式是否可以利用外鍵功能而不會遇到問題？
- 如果我們僅將數據庫用於儲存和管理應用程序/腳本層的“關係”，那麼 noSQL/redis 會更好嗎？
讓我們從您的第一個連結開始。它清楚地說：
在具有參照完整性的大型數據庫上工作表現不佳。
這是正確的。只是您可能不知道“大型數據庫”是 TB 大小，表中有數十億行。一個簡單的選擇可能會級聯成數億個相關元素被刪除，然後你就會遇到性能問題。
對於正常的小型數據庫（例如 wordpress 日誌或大多數 CMS）來說，這不是問題——如果您執行 facebook 之類的操作或處理財務模擬數據，它就會變成問題。我經常處理數十億行表並刪除在事務之外的儲存過程中工作的 x 批次 - 因為最終刪除可能很容易清理數億行。
他們會從 MySQL 轉向 NoSQL 類型的伺服器中受益嗎？
幾乎不。當專業人士酌情使用它們時，它們很有用。
另一方面，應用程序編碼的方式是否可以利用外鍵功能而不會遇到問題？
是的。
如果我們僅將數據庫用於儲存和管理應用程序/腳本層的“關係”，那麼 noSQL/redis 會更好嗎？
我曾經對一家不使用參照完整性（以提高性能）的銀行進行技術升級的應用程序審查。將數據載入到 SQL Server（它應該替換他們老化的 Adabas 安裝）它失敗了，違反了完整性約束。發生 40% 的歷史記錄是無效的，因為某些*****已刪除不再使用的查找表值（例如舊的客戶分類程式碼，它被替換為所有活躍的客戶，而不是舊的）。從來沒有出現過參照完整性警告。結果是一些人被解雇了，一個問題被困在了解決方法中，並且在頂部建構了一個部分無用的數據倉庫。
在應用程序/腳本層管理關係就這麼多。錯誤將會發生。數據很有價值，應用程序會發生變化。
大多數抱怨 SQL 級別特性的人會更建議閱讀有關它們的書，並嘗試理解它們，而不是抱怨。可悲的是，網際網路上的許多建議都是由拒絕閱讀文件的人撰寫的。始終要小心。大多數對 NoSql 的建議都是基於無知。