使用帶有偽外鍵的 RDBMS VS 使用 NoSQL 解決方案
根據我們組織的一些數據庫管理員的說法，通常不建議在我們的 MySQL 數據庫中實際實施外鍵關係。相反，最好用偽外鍵 ID 列簡單地表示這一點，並為外鍵強制執行額外的應用程序處理。原因是隨著數據庫向外擴展，插入和刪除（尤其是級聯的）變得非常昂貴。
但這不會破壞 RBDMS 的初衷嗎？據我了解，似乎首先使用 RBDMS 的最大原因之一（除了強制 ACID 屬性）是確保涉及相關（即通過 FK 由聯結表綁定）對象的應用程序查詢處理被最小化。
那麼使用帶有附加應用程序處理的偽外鍵通常更實用嗎？而且，如果是這樣，您為什麼還要使用 RBDMS？我認為原因是應用程序處理仍然比 NoSQL 解決方案稍微少一些（而且更直接）？
TL;博士。除非您有一個引人注目的小眾案例， 否則請充分利用您的 RDBMS 的功能！
嗯……你說：
我們組織的一些數據庫管理員
其他人怎麼說？
你還寫：
最好用偽外鍵 ID 列簡單地表示它
究竟什麼是“偽外鍵 ID 列”？
您從使用s ( s) 獲得的全部意義（也是最大的好處）是您可以自動執行( ) - 見下文。數據庫系統的這種功能在更改數據時故意不靈活。這是為了您的開發人員的利益、您的 DBA 的利益、您的公司的利益，最重要的是，為了您的客戶的利益！
FOREIGN KEY``FK``Declarative Referential Integrity``DRI現代 RDBMS（無論如何都是大多數）本身就是一個複雜的程式環境，您可以利用它來盡可能接近您的數據來保持****對數據的最大控制。
您可以有效地對數據旁邊的數據進行細粒度控制，這是它的最佳位置。您的數據庫是防禦惡意應用程序（大部分是誠實的錯誤）和/或 DBA/系統管理員（再次，大部分是誠實的）以一種使其不一致的方式修改您的數據的最後堡壘。
不一致的數據可能比無用更糟糕 - 如果您知道您的數據已損壞，您可以從備份中恢復，但如果數據不一致，則可能會根據錯誤的前提做出關鍵任務決策！
您的 DBA 說：
隨著數據庫的橫向擴展，插入和刪除（尤其是級聯的）變得非常昂貴
然而，您似乎正在使用
pseudo foreign-key ID columns？這增加了它自己的成本 - 例如，對於INSERT一個子表，你必須（在應用程序中 - 並且在一個事務中）查詢數據庫（大概檢查父母的存在？）然後做你的（一致的）INSERT然後COMMIT?對於父級上的 a
DELETE和/或 anUPDATE，您必須檢查子級的存在，然後根據規則（ing）檢查子級，然後/DELETE父級都在一個事務中。在數據庫中設置 DRI 可以消除所有成本！請參閱此處和該執行緒的其餘部分。UPDATE``CASCAD``DELETE``UPDATE在我看來，變得更加昂貴的是失去的數據、孤兒記錄、沒有孩子的父母和憤怒的客戶的深夜電話，威脅要關閉你的公司及其軟體！
是的，執行 DRI 需要付出一定的代價。您的DBA建議您在應用程序****中執行此操作-但與使用RDBMS（參見上面的範例）。
- 應用程序來來去去。
- 語言來來去去（也許除了 C）。
- 框架來來去去。
- 10 到 20 年前是 XML，現在全是 JSON……
- Fortran/Cobol -> C -> C++ -> Java -> Scala -> Clojure -> Go -> Rust -> 不管你自己擁有…
- 數據是永久性的（或者至少，與上述數據相比，壽命非常長）！
最年輕的主流 RDBMS 產品 MySQL 於23 年前首次發布，它只是作為 Oracle（1979 年）、Ingres（80 年代中期或更早- 在當時很重要）等系統的輕量級副本， Sybase/MS SQL Server（1984 年）、PostgreSQL（也是 80 年代中期或更早）和 Interbase/Firebird（1984 年——當時也很重要）。
因此，這些系統的存在時間比您的應用程序要長得多。
您的 DBA 提議的是重新設計輪子——這個輪子每天在全世界的銀行、超市、工廠、辦公室和倉庫（非詳盡列表）中為數百萬使用者執行良好。
這裡有幾個主要問題。
- 誰知道？也許您擁有一支優秀的熱門程序員團隊，他們可以在不到 3 年的時間內實現主流 RDBMS 功能？呃……我為什麼不買那個場景？好吧，上面兩個開源系統中的“最便宜”（但到目前為止更好的恕我直言）——PostgreSQL——花費了 1500 萬美元和 269 個工作年的努力，而 MySQL 花費了 6350 萬美元和 1155 個工作年。你覺得你的團隊能做到嗎？
- 你有你的數據庫軟體——通過試圖規避/重寫它的 DRI 功能，你實際上是在丟掉他們多年的程式工作和測試以及他們（字面上）數百萬最終使用者的（有效）測試。
- 假設，一個陽光明媚的早晨，您的老闆/客戶/稅務機關/誰決定您需要編寫一個新的應用程序來處理您的數據庫？您將不得不重新實施所有****的DRI ！並且可能使用不同的語言，因為您的老闆在一些機上雜誌上讀到X 是目前語言。就像重逢一樣！
déjà vuGroundhog Day然後，你僱傭了一個契約天才程序員，他為他的本科論文用 X 編寫了一個系統。他不知道table_W 中的column_A 是table_Z 中column_B 的子項，因此他每天愉快地編寫數百行程式碼，這些程式碼可以流暢而快速地處理您的測試數據。
然後它與客戶一起登陸，他們開始注意到記錄失去 - 總和/記錄計數不正確。你的承包商已經搬到了一家初創公司 (
Cowboys 'R Us)，而你只剩下抱著孩子了！（這種情況也可能在您目前的設置中出現）。看看這三篇文章
- 我迫不及待地等待 NoSQL 消亡- 對 NoSQL 的一種公認的黃疸觀點，但如果您考慮以下文章，則並非如此，
- 當橡膠遇到道路並且（咳咳……）利用 NoSQL 的最終一致性 ( BASE ) 模型時會發生什麼，
- 最後，NoSQL 系統現在是如何發現 SQL 和一致性並不是真的那麼糟糕- 回來ACID/SQL，一切都被原諒了！
我並不是說 NoSQL 系統沒有“利基市場”，只是它們確實擁有一個****利基市場（與上述內容大致相同）。除非您有與 NoSQL 案例明確一致的非常具體的需求，否則最好避免使用它們（恕我直言）。
如果上述內容不能說服您，請考慮以下最後幾點：
更多戰爭故事，獻給第 8 章的粉絲！“現在準備好閱讀有關‘世界上最糟糕的甲骨文項目’的所有內容。”——喬納森·劉易斯。
本章描述了開發 Oracle 數據庫應用程序中一些最常見的錯誤。你肯定會認出其中一些，因為有很多人固執地堅持某些信念。我知道當我遇到以下常見論點時，我喜歡提出他的幾個觀點：
- 我們希望我們的應用程序是“數據庫獨立的”。
- 我們將在應用程序級別檢查數據完整性，而不是利用 Oracle 的約束檢查能力。
注意-第2點。-這正是您打算做的！
- 看看Brian Aker關於 NoSQL 的有趣演講-他指出 NoSQL 適用於處理陳舊數據的即席查詢，只是 SQL 也擅長切片和切塊數據。
- 儘管使用 SQL的關鍵優勢是您無需編寫新的 Map-Reduce 作業或任何分析數據的內容，您只需編寫查詢，等等，您就完成了！如果您沒有
FOREIGN KEY在 RDBMS 中使用 s，那麼您實際上處於 SQL 和 NoSQL 之間的中間位置！有關於 FK 是不必要的成本的老婦人的故事。由於（出於好的原因，但現在可能是遺留問題，尤其是空間原因）某些 RDBMS 沒有/不會自動在外鍵欄位上創建索引（這在大多數情況下應該這樣做），這一概念得以保持。這導致了一個錯誤的觀點，即外鍵是成本而沒有好處，這對於大多數案例來說是****不正確的！
你說：
如果是這樣，您為什麼還要使用 RBDMS？
這個問題問得好。如果您沒有將 RDBMS 用作 RDBMS，那麼為什麼還要使用它呢？只需將數據放入記事本/vi！
您應該與管理層進行認真的座談，並解釋為什麼使用 RDBMS 的功能是一個好主意。此外，我會要求您的（No-
FK）人證明不使用FOREIGN KEYs 是合理的。除非您的公司有一個真正且緊迫的 NoSQL 利基市場，否則請向他們指出 Micheal Stonebraker 和/或 Jonathan Lewis 在這方面的作品。最後，我給你的建議是，如果你的公司/管理層堅持追求這種瘋狂，那就是跑得非常非常遠，非常非常快！你最終會陷入不斷滅火的情況，03:30 從床上被叫醒，更糟糕的是，你將沒有機會提高自己的技能或學習任何有價值的東西。