SQL 和關系數據庫管理系統（RDBMS）都是在上世紀70 年代早期開發的。Edgar F. Codd 開發了 RDBMS，而 Donald D. Chamberling 和 Raymond F. Boyce 開發了 SQL。二者都誕生在計算機技術的早期，而且在 90% 的時間里都非常有效，使得數據庫成為了一項 “已經被解決的問題”。就像 MailChimp 已經成為了發送新聞簡訊的同義詞。如果你想使用數據庫，你就得使用 RDBMS 和 SQL。不過，仍然還是有人使用其他 email 軟件，正如還是用人使用非 SQL 的數據庫。但即使是存在著其他可供使用的數據庫技術，SQL 依舊占據霸主地位。以下 8 條，就是我們在 SQL 誕生 50 年后依舊使用它的原因。
SQL 最初基于關系代數和元組關系演算——由 Codd 特別為關系數據庫開發的兩種數學模式。所以，SQL 是特別為處理數據而設計的，而事實證明，它非常善于存取和組織數據。那么第一個原因就是：作為一種數據庫技術，SQL 非常稱職。
RDBMS 已經問世很長時間了，所以已經用于了大量不同的情況。在 “前網絡時代”，它就作為線下數據庫使用，到如今，有了重大修改的 SQL 數據庫，仍在 Facebook 這樣的全球性 app 中扮演中核心角色——RDBMS 和 SQL 已經久經沙場。而在眾多產品中運行過的無數個小時，證明了它們是可信賴的。有些軟件就是能解決問題，尤其是當你在處理充斥著丟失、損壞和失敗等問題的數據庫時，這種優勢尤為明顯。作為成熟的軟件，SQL 有著備份計劃、變化管理和操作嚴謹性，而這些會使棘手的情況大為好轉。
當事物存在一段時間之后，圍繞著它的知識體系就會被建立。SQL 也不例外。最過去的時間里，大量的 SQL 知識被寫成文檔，SQL 社區快速發展，許許多多的技術人才成長了起來。因為 SQL 社區如此活躍，SQL 文檔又如此豐富，所以它便吸引了大量的人才和商業活動。而又因為 SQL 吸引了大量的人才，所以 SQL 社區更加壯大，知識更加深入。
計算機語言發展了這么久，直到今天，SQL 仍然是一種非常易學的語言。短短幾天，你就可以學會基本的功能，能夠進行查詢和返回數據。非常簡單。即使是傳統意義上的非技術崗位，比如市場，公司高管，以及非技術性的產品經理，都會去學習基本的 SQL 功能，來支持他們的工作。而深入地了解 SQL 基于的關系型數據庫系統，完全是另一件事。對于大多數只需要使用查詢功能的人來說，SQL 真是太好用了。
因為有半數的開發者都會使用 SQL 和 RDBMS，所以我們可以肯定地說，這兩者高度普及。這絕不是一件壞事。正如上文所說，由于使用人數多，相關知識和社區得以快速發展。而又由于其簡單，故而對于開發者以及其他相關人員來說，SQL 知識幾乎是常識。于是，相關知識就極易在公司、產業之間傳播，人才儲備充足。而這又反過來促進了知識的創造和社區的成長。可見，SQL 數據庫普及度極高的特性，已經為其自身的成長構筑了一個良性循環。
從 1995 年至今，開源的 SQL 技術（MySQL 和 PostgreSQL）已經成為了主要的 SQL 數據庫技術。2023年，Stack Overflow面向90000名開發人員進行的一項調查顯示，PostgreSQL在數據庫引擎的選擇上領先于MySQL，這與往年的調查相比有了顯著變化。這種向開源 SQL 數據庫切換的趨勢，對于已經規模龐大的 SQL 社區來說是一件好事。同時這種趨勢的存在也印證了，SQL 社區中的開發者們正在努力地使 SQL 變得更好。
能用 SQL server 做好的事情就別寫代碼。這句話背后的邏輯是，在絕大多數情況下，SQL 都能找到最有效的辦法來完成你的任務，而且做得比任何能自己寫代碼來解決的人更好。舉個例子。假設我們需要建立一份關于 “加利福尼亞 2020 年第三季稅收” 的報告，具體做法是，選出列表中加利福尼亞的用戶，并按照數據進行排列。那么你只需要一句 SQL 語句就可以完成：SELECT SUM(Value_USD) AS California_Revenue_Q3 FROM Transactions WHERE Location = ‘California’ AND DATEPART(q, Date) = 3 AND YEAR(Date) = 2020;
而如果你要按照不同的地區對數據進行分解，那么 SQL 語句是這樣的：SELECT Location, SUM(Value_USD) AS Revenue_Q3 FROM Transactions WHERE DATEPART(q, Date) = 3 AND YEAR(Date) = 2020 GROUP BY Location ORDER BY Location;
SELECT TOP 5 Location, SUM(Value_USD) AS Revenue_Q3 FROM Transactions WHERE DATEPART(q, Date) = 3 AND YEAR(Date) = 2020 GROUP BY Location ORDER BY SUM(Value_USD) DESC;
如果你想用其他語言來進行這些查詢，情況就會復雜很多，既耗時間，語句也長得多。設計 SQL 就是為了切割數據，而且看起來 SQL 做得非常好。畢竟，不是數據因計算而存在，而是計算因數據而存在。
八、SQL/RDBMS 和 NoSQL/DBMS 數據庫各司其職
數據庫是工具。工具不應該只有斧子，還應該有扳手，螺絲刀，鋸子等等。每一種工具各司其職，解決不同的問題。而每一種數據庫都長于一些事情，而短于另一些事情。
當你無法預見數據匯總或數據用途的所有可能性，但又需要表示一個系統中各部分的關系時，關系數據庫就是最好的選擇。而且老實說，大部分系統在這方面做得并不好。再者，SQL 語言本身提供了一種用戶友好型的數據組織方式。
SQL/RDBMS 只是眾多工具中的一種，且剛好在很多情況下都是切實能用的那種。而當需要保證數據的完整性、一致性時（比如金融領域），SQL/RDBMS 就是最好用的工具。
SQL 數據庫有它們自身的缺點，且對于某些工作來說，并不是最好的選擇。但在大部分情況下，它們可以輕松打敗其他非 SQL 數據庫。
有些人會擔心數據規模的問題，但實際上，只有很小一部分人需要解決 RDBMS 的擴容問題——畢竟你不是 Facebook 或者 Google。因此，你仍然可以用 SQL 數據庫管理數一百萬計的用戶信息，而不出現任何問題。
更何況，只要知道如何權衡利弊，RDBMS 是可以擴容的。
盡管數不清的其他數據庫系統和技術，都在不斷擴大著使用人群，但是，毫無疑問地，SQL 數據庫在可預見的未來甚至更遠，會一直發揮作用。隨著大數據，深度學習和物聯網的到來，即使 SQL 數據庫再流行 50 年也不奇怪。
確實，SQL 數據庫是有缺點的。但在絕大多數的案例中，龐大的社區，簡單的語言，以及有強大的 RDBMS 作為其基礎，使得 SQL 成為了最好的選擇之一。
為什么我們在 SQL 誕生 50 年后還一直使用它呢？因為它能用，而且在 90% 的情況中都能完成任務。這對于身處越來越復雜的技術與集成環境中的開發者而言，就是最大的優點。
該文章在 2024/5/7 17:25:49 編輯過
400 186 1886
