SQL 誕生 43 年了!為什麼我們仍在使用它的 8 個原因

2017-05-04    分類:資料庫、程式設計開發、首頁精華0人評論發表於2017-05-04

本文由碼農網 – LifeApprentice原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃

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已經成為了傳送新聞簡訊的同義詞。如果你想使用資料庫,你就得使用RDBMS和SQL。

不過,仍然還是有人使用其他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語句就可以完成:

SELECT SUM(Value_USD) AS California_Revenue_Q3 FROM Transactions WHERE Location = ‘California’ AND DATEPART(q, Date) = 3 AND YEAR(Date) = 2017;

而如果你要按照不同的地區對資料進行分解,那麼SQL語句是這樣的:

SELECT 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個區域:

SELECT 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 is 43 years old - here’s 8 reasons we still use it today
翻譯作者:碼農網 – LifeApprentice
轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]

相關文章