譯者：靖饃。
考慮到 SQL 的流行和成功，本文更像是乙個悖論研究。 SQL 可能笨拙而冗長，但開發人員通常發現它是提取所需資料的最簡單、最直接的方法。 當查詢編寫正確時，它可能會快如閃電，而當查詢失敗時，它可能會出奇地慢。 它已經存在了幾十年，但新功能不斷新增。
這些矛盾並不重要，因為市場已經表明，SQL是許多人的首選，即使有更新、更強大的選擇。 從最小的公司到最大的大公司，世界各地的開發人員都了解 SQL。 他們依靠它來組織所有資料。
SQL 的 ** 模型非常流行，以至於許多非 SQL 專案最終新增了 SQLish 介面，因為使用者需要它。 即使是“NoSQL”運動——它是為了擺脫舊正規化而發明的——最終似乎也輸給了 SQL。
SQL 的侷限性可能不足以完全拋棄它。 開發人員也可能永遠不會打算將所有資料遷移到 SQL 之外。 但 SQL 的問題是真實存在的，足以給開發人員帶來壓力，增加延遲，甚至需要重新設計某些專案。
以下是我們想要放棄 SQL 的 9 個原因，即使我們知道這可能是不可能的。
關係模型是**的粉絲，所以我們一直在構建它。 這對於小型甚至正常大小的資料庫來說都很好，但在面對真正的大規模資料庫時，模型就會崩潰。
有些人試圖通過新舊結合來解決問題，例如將分片整合到舊的開源資料庫中。 新增圖層似乎使資料更易於管理，並提供無限的規模。 但這些增加的層可以隱藏危險。 根據分片中儲存的資料量，select 或 join 的處理時間可能會有很大差異。
分片還迫使資料庫管理員 （DBA） 考慮資料儲存在不同機器上的可能性，甚至可能儲存在不同的地理位置上。 沒有經驗的管理員在開始跨表搜尋時可能會感到困惑，而沒有意識到資料儲存在不同的位置。 模型有時會從檢視中抽象出位置。
一些 AWS 機器配備了 24TB 的 RAM，因為一些資料庫使用者需要這麼多。 他們的 SQL 資料庫中有如此多的資料，而且這樣執行得更好。
SQL 可能是一種“常青”語言，但它並不是特別適合較新的資料交換格式，如 JSON、YAML 和 XML。 它們都支援比 SQL 更具分層性和靈活性的格式。 SQL 資料庫的核心仍然停留在關係模型中，充滿了各種**。
市場會想方設法掩蓋這種常見的抱怨。 使用正確的膠水新增不同的資料格式（例如 JSON）相對容易**，但您將付出浪費時間的代價。
一些 SQL 資料庫現在能夠對更現代的資料格式（如 JSON、XML、GraphQL 或 YAML）進行編碼和解碼，作為本機功能。 但在內部，資料通常使用相同的舊模型進行儲存和索引。
在這些格式之間轉換資料需要多少時間？以更現代的方式儲存資料不是更容易嗎？一些聰明的資料庫開發人員繼續嘗試，但奇怪的是，他們經常使用某種SQL解析器。
資料庫可以將資料儲存在表中，但需要程式設計師編寫處理物件的 **。 設計資料驅動應用程式的大部分工作似乎是找出從資料庫中提取資料並將其轉換為業務邏輯可以處理的內容的最佳方法的最佳方法。 然後，必須通過將物件中的資料字段轉換為 SQL Upsert 來取消組合資料。 有沒有辦法將資料儲存為即用型格式？
原始 SQL 資料庫專為批處理分析和互動式模式而設計。 具有較長處理管道的流資料模型是乙個相對較新的想法，它並不完全匹配。
主要的SQL資料庫是幾十年前設計的，當時的模型設想資料庫可以獨立執行，並像某種預言機一樣回答查詢。 有時他們反應迅速，有時則不然。 這就是批處理的工作原理。
一些最新的應用程式需要更好的實時效能 - 不僅僅是為了方便，還因為應用程式需要它。 在現代流媒體世界中，缺乏實時功能是行不通的。
為這些市場設計的最新資料庫非常重視速度和響應能力。 它們不提供會導致延遲的複雜 SQL 查詢。
關聯式資料庫的強大之處在於將資料分解為更小、更簡潔的表。 但是，問題也隨之而來。
使用聯接動態重組資料通常是作業中計算成本最高的部分，因為資料庫必須處理所有資料。 當資料開始超過 RAM 時，問題就開始了。
對於那些正在學習 習 SQL 的人來說，加入可能會令人困惑。 弄清楚內部聯接和外部聯接之間的區別只是乙個開始。 找到將多個聯接連線在一起的最佳方法更加困難。 內部優化器可能會有所幫助，但是當資料庫管理員要求特別複雜的組合時，他們無能為力。
“nosql”運動的乙個偉大想法是將使用者從列中解放出來。 如果有人想向條目新增新值，他們可以選擇他們想要的任何標籤或名稱。 無需更新架構即可新增新列。
SQL防禦者在這個模型中只看到混亂。 他們喜歡表格的順序，不希望開發人員急於新增新字段。 它們有一定道理，但新增新列可能非常昂貴且耗時，尤其是在大型表中。 將新資料放在單獨的列中並使用聯接進行匹配會增加更多的時間、成本和複雜性。
資料庫公司和研究人員花費了大量時間開發出色的優化器，這些優化器可以分解查詢並找到對其操作進行排序的最佳方法。
好處可能很大，但優化器可以做的事情是有限的。 如果查詢需要特別大或特別精細的響應，優化器不能只是說“你真的確定嗎？“它必須收集答案並按照它的指示去做。
一些資料庫管理員在應用程式開始擴充套件之前沒有意識到這一點。 早期優化足以在開發過程中處理測試資料集。 但在關鍵時刻，優化器無法做更多的事情。
開發人員經常面臨兩難境地，一是想要更快效能的使用者，另一是不想為更大、更昂貴的硬體付費。 一種常見的解決方案是將表非規範化，這樣就不需要複雜的聯接或跨表操作。
這不是乙個糟糕的技術解決方案，而且它經常獲勝，因為磁碟空間已經變得比處理能力便宜。 但是非規範化也拋棄了SQL和關聯式資料庫理論的最佳部分。 當資料庫變成乙個長 csv 檔案時，所有這些花哨的資料庫功能幾乎都消失了。
多年來，開發人員一直在向 SQL 新增新功能，其中一些功能非常出色。 但另一方面，有一些新功能可能會導致效能問題。 一些開發人員警告說，“你應該特別小心子查詢，因為它們會減慢所有操作的速度”。 其他人則說，“選擇像公共表表示式、檢視或 Windows 這樣的子集太複雜了。
例如，視窗函式旨在通過加快計算結果（例如平均值）來加快基本資料分析的速度。 但是，許多 SQL 使用者會發現和使用一些附加功能。 在大多數情況下，他們會嘗試新功能，並且只有在他們的機器像爬行一樣緩慢時才會注意到這些問題。 然後，他們需要一些有經驗的資料庫管理員來解釋正在發生的事情以及如何修復它。