Stack Overflow（IT技術問答網站）今年開展了一項調查， 共有64000名開發者參與。 調查顯示， SQL是目前第二大程式設計語言， 有50%的開發者（包括Web， 桌面， 運維， 資料等方向）在使用SQL。 唯一打敗了SQL的， 是年齡只有SQL一半的JavaScript。
開發者最常用的語言排行, Stack Overflow 2017
這對於一門已經43歲的語言來說是一個了不起的成就， 況且還是在變化日新月異的軟體和科技領域。
當然， C和C++的年齡與SQL不相上下， 但即使是把這兩種語言加在一起也沒有SQL那麼流行。 這可能就要由開發者們對各種資料庫技術的使用情況來解釋了：
資料庫技術使用比例排行, Stack Overflow 2017
可以看到， SQL相關技術牢牢地佔據資料庫技術使用比例的前幾位。 雖然這些技術遠遠不是最受歡迎的， 不過好在有PostgreSQL這個意外：
最受歡迎的資料庫技術排行, Stack Overflow 2017
而且SQL語言雖然是最流行的語言， 但也沒有得到太多的喜愛：
最受歡迎的程式設計語言排行, Stack Overflow 2017
但也有一件好事， SQL是最不被害怕的語言……
最令人畏懼的語言排行, Stack Overflow 2017
綜上所述， 調查資料告訴我們， SQL是使用最廣泛但卻不怎麼受歡迎的語言……
為什麼我們仍在使用SQL？
SQL和關聯式資料庫管理系統（RDBMS）都是在1970年代早期開發的。 Edgar F. Codd 開發了RDBMS， 而Donald D. Chamberling 和Raymond F. Boyce 開發了SQL。
二者都誕生在電腦技術的早期， 而且在90%的時間裡都非常有效， 使得資料庫成為了一項“已經被解決的問題”。 就像MailChimp已經成為了發送新聞簡訊的同義詞。 如果你想使用資料庫，
不過， 仍然還是有人使用其他email軟體， 正如還是用人使用非SQL的資料庫。 但即使是存在著其他可供使用的資料庫技術， SQL依舊佔據霸主地位。
以下8條， 就是我們在SQL誕生43年後依舊使用它的原因。
1. 資料處理能力
SQL最初基於關聯代數和元組關聯計算法——由Codd特別為關聯式資料庫開發的兩種數學模式。
所以，SQL是特別為處理資料而設計的，而事實證明，它非常善於存取和組織資料。
那麼第一個原因就是：作為一種資料庫技術，SQL非常稱職。
2.實踐檢驗
RDBMS已經問世很長時間了，所以已經用於了大量不同的情況。在“前網路時代”，它就作為線下資料庫使用，到如今，有了重大修改的SQL資料庫，仍在Facebook這樣的全球性app中扮演中核心角色——RDBMS和SQL已經久經沙場。而在眾多產品中運行過的無數個小時，證明了它們是可信賴的。
有些軟體就是能解決問題，尤其是當你在處理充斥著丟失、損壞和失敗等問題的資料庫時，這種優勢尤為明顯。作為成熟的軟體，SQL有著備份計畫、變化管理和操作嚴謹性，而這些會使棘手的情況大為好轉。
因此，SQL資料庫幾乎總是最好的選擇。
3.知識和社區
當事物存在一段時間之後，圍繞著它的知識體系就會被建立。SQL也不例外。最過去的時間裡，大量的SQL知識被寫成文檔，SQL社區快速發展，許許多多的技術人才成長了起來。
因為SQL社區如此活躍，SQL文檔又如此豐富，所以它便吸引了大量的人才和商業活動。而又因為SQL吸引了大量的人才，所以SQL社區更加壯大，知識更加深入。
這就是多年來SQL的發展狀況。
4.簡單
電腦語言發展了這麼久，直到今天，SQL仍然是一種非常易學的語言。短短幾天，你就可以學會基本的功能，能夠進行查詢和返回資料。非常簡單。
即使是傳統意義上的非技術崗位，比如市場，公司高管，以及非技術性的產品經理，都會去學習基本的SQL功能，來支持他們的工作。
而深入地瞭解SQL基於的關係型數據庫系統，完全是另一件事。對於大多數只需要使用查詢功能的人來說，SQL真是太好用了。
5. 高度普及
因為有半數的開發者都會使用SQL和RDBMS，所以我們可以肯定地說，這兩者高度普及。這絕不是一件壞事。正如上文所說，由於使用人數多，相關知識和社區得以快速發展。而又由於其簡單，故而對於開發者以及其他相關人員來說，SQL知識幾乎是常識。
於是，相關知識就極易在公司、產業之間傳播，人才儲備充足。而這又反過來促進了知識的創造和社區的成長。
可見，SQL資料庫普及度極高的特性，已經為其自身的成長構築了一個良性迴圈。
6. 開源及互通性
從1995年至今，開源的SQL技術（MySQL和PostgreSQL）已經成為了主要的SQL資料庫技術。
開發者使用的資料庫技術排行, Stack Overflow 2017
其實，PostgreSQL是2017年開發者最希望使用的資料庫技術之一。儘管它領先的幅度很小，且被MongoDB大幅超越。
2017開發者最希望使用的資料庫技術排行, Stack Overflow 2017
這種向開源SQL資料庫切換的趨勢，對於已經規模龐大的SQL社區來說是一件好事。同時這種趨勢的存在也印證了，SQL社區中的開發者們正在努力地使SQL變得更好。
7. 能用SQL誰還寫代碼？
坊間流傳著這樣一句話……
能用SQL server做好的事情就別寫代碼。
這句話背後的邏輯是，在絕大多數情況下，SQL都能找到最有效的辦法來完成你的任務，而且做得比任何能自己寫代碼來解決的人更好。
舉個例子。假設我們需要建立一份關於“加利福尼亞2017年第三季稅收”的報告，具體做法是，選出列表中加利福尼亞的使用者，並按照資料進行排列。那麼你只需要一句SQL語句就可以完成：
1SELECT SUM(Value_USD) AS California_Revenue_Q3 FROM Transactions WHERE Location = ‘California’ AND DATEPART(q, Date) = 3 AND YEAR(Date) = 2017;而如果你要按照不同的地區對資料進行分解，那麼SQL語句是這樣的：
1SELECT Location, SUM(Value_USD) AS Revenue_Q3 FROM Transactions WHERE DATEPART(q, Date) = 3 AND YEAR(Date) = 2017 GROUP BY Location ORDER BY Location;如果你想得到稅收最高的5個區域：
1SELECT TOP 5 Location, SUM(Value_USD) AS Revenue_Q3 FROM Transactions WHERE DATEPART(q, Date) = 3 AND YEAR(Date) = 2017 GROUP BY Location ORDER BY SUM(Value_USD) DESC;如果你想用其他語言來進行這些查詢，情況就會複雜很多，既耗時間，語句也長得多。設計SQL就是為了切割資料，而且看起來SQL做得非常好。畢竟，不是資料因計算而存在，而是計算因數據而存在。
8.SQL/RDBMS和 NoSQL/DBMS 資料庫各司其職
資料庫是工具。工具不應該只有斧子，還應該有扳手，螺絲刀，鋸子等等。每一種工具各司其職，解決不同的問題。而每一種資料庫都長於一些事情，而短於另一些事情。
當你無法預見資料匯總或資料用途的所有可能性，但又需要表示一個系統中各部分的關係時，關聯式資料庫就是最好的選擇。而且老實說，大部分系統在這方面做得並不好。再者，SQL語言本身提供了一種使用者友好型的資料組織方式。
SQL/RDBMS只是眾多工具中的一種，且剛好在很多情況下都是切實能用的那種。而當需要保證資料的完整性、一致性時（比如金融領域），SQL/RDBMS就是最好用的工具。
SQL資料庫有它們自身的缺點，且對於某些工作來說，並不是最好的選擇。但在大部分情況下，它們可以輕鬆打敗其他非SQL資料庫。
有些人會擔心資料規模的問題，但實際上，只有很小一部分人需要解決RDBMS的擴容問題——畢竟你不是Facebook或者Google。因此，你仍然可以用SQL資料庫管理數一百萬計的使用者資訊，而不出現任何問題。
更何況，只要知道如何權衡利弊，RDBMS是可以擴容的。
再用43年？
儘管數不清的其他資料庫系統和技術，都在不斷擴大著使用人群，但是，毫無疑問地，SQL資料庫在可預見的未來甚至更遠，會一直發揮作用。隨著大資料，深度學習和物聯網的到來，即使SQL資料庫再流行43年也不奇怪。
確實，SQL資料庫是有缺點的。但在絕大多數的案例中，龐大的社區，簡單的語言，以及有強大的RDBMS作為其基礎，使得SQL成為了最好的選擇之一。
為什麼我們在SQL誕生43年後還一直使用它呢？因為它能用，而且在90%的情況中都能完成任務。這對於身處越來越複雜的技術與集成環境中的開發者而言，就是最大的優點。
譯文連結：http://www.codeceo.com/article/why-we-use-43-years-old-sql.html
所以，SQL是特別為處理資料而設計的，而事實證明，它非常善於存取和組織資料。
那麼第一個原因就是：作為一種資料庫技術，SQL非常稱職。
2.實踐檢驗
RDBMS已經問世很長時間了，所以已經用於了大量不同的情況。在“前網路時代”，它就作為線下資料庫使用，到如今，有了重大修改的SQL資料庫，仍在Facebook這樣的全球性app中扮演中核心角色——RDBMS和SQL已經久經沙場。而在眾多產品中運行過的無數個小時，證明了它們是可信賴的。
有些軟體就是能解決問題，尤其是當你在處理充斥著丟失、損壞和失敗等問題的資料庫時，這種優勢尤為明顯。作為成熟的軟體，SQL有著備份計畫、變化管理和操作嚴謹性，而這些會使棘手的情況大為好轉。
因此，SQL資料庫幾乎總是最好的選擇。
3.知識和社區
當事物存在一段時間之後，圍繞著它的知識體系就會被建立。SQL也不例外。最過去的時間裡，大量的SQL知識被寫成文檔，SQL社區快速發展，許許多多的技術人才成長了起來。
因為SQL社區如此活躍，SQL文檔又如此豐富，所以它便吸引了大量的人才和商業活動。而又因為SQL吸引了大量的人才，所以SQL社區更加壯大，知識更加深入。
這就是多年來SQL的發展狀況。
4.簡單
電腦語言發展了這麼久，直到今天，SQL仍然是一種非常易學的語言。短短幾天，你就可以學會基本的功能，能夠進行查詢和返回資料。非常簡單。
即使是傳統意義上的非技術崗位，比如市場，公司高管，以及非技術性的產品經理，都會去學習基本的SQL功能，來支持他們的工作。
而深入地瞭解SQL基於的關係型數據庫系統，完全是另一件事。對於大多數只需要使用查詢功能的人來說，SQL真是太好用了。
5. 高度普及
因為有半數的開發者都會使用SQL和RDBMS，所以我們可以肯定地說，這兩者高度普及。這絕不是一件壞事。正如上文所說，由於使用人數多，相關知識和社區得以快速發展。而又由於其簡單，故而對於開發者以及其他相關人員來說，SQL知識幾乎是常識。
於是，相關知識就極易在公司、產業之間傳播，人才儲備充足。而這又反過來促進了知識的創造和社區的成長。
可見，SQL資料庫普及度極高的特性，已經為其自身的成長構築了一個良性迴圈。
6. 開源及互通性
從1995年至今，開源的SQL技術（MySQL和PostgreSQL）已經成為了主要的SQL資料庫技術。
開發者使用的資料庫技術排行, Stack Overflow 2017
其實，PostgreSQL是2017年開發者最希望使用的資料庫技術之一。儘管它領先的幅度很小，且被MongoDB大幅超越。
2017開發者最希望使用的資料庫技術排行, Stack Overflow 2017
這種向開源SQL資料庫切換的趨勢，對於已經規模龐大的SQL社區來說是一件好事。同時這種趨勢的存在也印證了，SQL社區中的開發者們正在努力地使SQL變得更好。
7. 能用SQL誰還寫代碼？
坊間流傳著這樣一句話……
能用SQL server做好的事情就別寫代碼。
這句話背後的邏輯是，在絕大多數情況下，SQL都能找到最有效的辦法來完成你的任務，而且做得比任何能自己寫代碼來解決的人更好。
舉個例子。假設我們需要建立一份關於“加利福尼亞2017年第三季稅收”的報告，具體做法是，選出列表中加利福尼亞的使用者，並按照資料進行排列。那麼你只需要一句SQL語句就可以完成：
1SELECT SUM(Value_USD) AS California_Revenue_Q3 FROM Transactions WHERE Location = ‘California’ AND DATEPART(q, Date) = 3 AND YEAR(Date) = 2017;而如果你要按照不同的地區對資料進行分解，那麼SQL語句是這樣的：
1SELECT Location, SUM(Value_USD) AS Revenue_Q3 FROM Transactions WHERE DATEPART(q, Date) = 3 AND YEAR(Date) = 2017 GROUP BY Location ORDER BY Location;如果你想得到稅收最高的5個區域：
1SELECT TOP 5 Location, SUM(Value_USD) AS Revenue_Q3 FROM Transactions WHERE DATEPART(q, Date) = 3 AND YEAR(Date) = 2017 GROUP BY Location ORDER BY SUM(Value_USD) DESC;如果你想用其他語言來進行這些查詢，情況就會複雜很多，既耗時間，語句也長得多。設計SQL就是為了切割資料，而且看起來SQL做得非常好。畢竟，不是資料因計算而存在，而是計算因數據而存在。
8.SQL/RDBMS和 NoSQL/DBMS 資料庫各司其職
資料庫是工具。工具不應該只有斧子，還應該有扳手，螺絲刀，鋸子等等。每一種工具各司其職，解決不同的問題。而每一種資料庫都長於一些事情，而短於另一些事情。
當你無法預見資料匯總或資料用途的所有可能性，但又需要表示一個系統中各部分的關係時，關聯式資料庫就是最好的選擇。而且老實說，大部分系統在這方面做得並不好。再者，SQL語言本身提供了一種使用者友好型的資料組織方式。
SQL/RDBMS只是眾多工具中的一種，且剛好在很多情況下都是切實能用的那種。而當需要保證資料的完整性、一致性時（比如金融領域），SQL/RDBMS就是最好用的工具。
SQL資料庫有它們自身的缺點，且對於某些工作來說，並不是最好的選擇。但在大部分情況下，它們可以輕鬆打敗其他非SQL資料庫。
有些人會擔心資料規模的問題，但實際上，只有很小一部分人需要解決RDBMS的擴容問題——畢竟你不是Facebook或者Google。因此，你仍然可以用SQL資料庫管理數一百萬計的使用者資訊，而不出現任何問題。
更何況，只要知道如何權衡利弊，RDBMS是可以擴容的。
再用43年？
儘管數不清的其他資料庫系統和技術，都在不斷擴大著使用人群，但是，毫無疑問地，SQL資料庫在可預見的未來甚至更遠，會一直發揮作用。隨著大資料，深度學習和物聯網的到來，即使SQL資料庫再流行43年也不奇怪。
確實，SQL資料庫是有缺點的。但在絕大多數的案例中，龐大的社區，簡單的語言，以及有強大的RDBMS作為其基礎，使得SQL成為了最好的選擇之一。
為什麼我們在SQL誕生43年後還一直使用它呢？因為它能用，而且在90%的情況中都能完成任務。這對於身處越來越複雜的技術與集成環境中的開發者而言，就是最大的優點。
譯文連結：http://www.codeceo.com/article/why-we-use-43-years-old-sql.html