SQL 已死，但 SQL 將永存！

在 SQL 被引入的 47 年中，它經歷了許多資料庫的誕生和消亡，也經歷了許多資料處理方式的誕生和消亡。

以下為譯文：

四十七年前，兩位年輕的IBM研究人員在資料庫上提出了一種新的語言，這是一種關係型語言，它奉行一切資料可以被宣告性地操作和容易操作的思想。自Don Chamberlin和Ramond Boyce出版《SEQUEL：結構化英語查詢語言》一書後的幾年裡，關係模型和SQL已經擴充套件並被大量的技術所採納，如OLTP、OLAP、物件資料庫、物件關聯式資料庫，甚至NoSQL等等。SQL同時也啟發了非關聯式資料庫的查詢語言設計：如SQL for Object-Database(用於物件資料庫的SQL)，SQL for Object-Relational（用於物件關係型資料庫的SQL），SQL for XML、SQL for Spatial、SQL for Search、SQL for JSON、SQL for Timeseries、SQL for Streams等等。每個BI工具都使用各種各樣的SQL與資料互動。實際上，SQL是最成功的第四代語言。

“SQL是一種只有它自己的力量才能超越它的神秘手段。”——Lukas Eder

正如Don最近所說的，SQL是基於關係代數的基礎，目的是透過提供一個類似於英語的查詢語言來更簡單地實現以下目標：

• 宣告性的語言和流程（而不是程式性的）
• 使語言可組合以幫助輕鬆編寫複雜的查詢
• 和Edger F Codd開發的關係模型共同工作

雖然大資料試圖為資料倉儲擴充套件和替換關係型系統，但它們試圖使用相同的SQL語言。Hive, Impala、Drill、BigSQL使用的語言都深受SQL啟發，最佳化器和執行類似於SQL的MPP執行。他們還定期新增新的SQL功能。所有這些都發生在你能想到的每種型別的資料儲存和模型上。SQL中資料儲存格式、資料模型和查詢處理的分離帶來了顯著的好處。

在SQL被引入的45年中，它經歷了許多資料庫的誕生和消亡，也經歷了許多資料處理方式的誕生和消亡。支援NoSQL運動的一些人暗示SQL和SQL資料庫不能將會消亡，即使是無意的。但SQL陣營已經邁步前進，Don Chamberlin最近說道：“當一種語言得到了普遍認可，以至於其他語言開始將自己定義為不是那種語言時，它必須做得非常好。”

另一方面，資料庫只是轉向了No-SQL。雖然目前對No-SQL的定義是“Not Only SQL”，但最初的想法是不使用SQL，而代之以其他語言和框架，如map-reduce。然而十年後，每個流行的NoSQL資料庫都有了一個SQL變體：如Couchbase的N1QL，Cassandra的CQL，Elastic的ElasticSearch。你會說，“MongoDB沒有SQL”。我會說，“眯眼想一想！你會看到一個非常簡單的SQL實現。” 透過在MongoDB中使用一個簡單的，有些程式化的，特別的設計，一些鬆散組合性的查詢，最佳化以及許多創新都可以使用SQL完成。

雖然關係模型非常成功，但是資料庫支援各種資料模型：如JSON, Graph, XML, Timeseries, Spatial, Wide-column, Columnar, Document等等。大多數（如果不是全部）資料庫都有自己的SQL版本。如N1Q1(SQL for Jason)、SQL/XML、SQL from InfluxDB、SQL/Spatial、CQL in Cassandra等等，甚至NoSQL資料庫也實現了SQL和SQL啟發的查詢語言。即使在新的酷炫的“資料科學”世界中，SQL技能也是強烈推薦的。Lukas Eder在他的“must-see”談話中闡述了這一點。有關他的談話，請參見相關連結。

現在，NoSQL資料庫相關的SQL專案要比SQL資料庫的專案多。

SQL 為何會成功？

1. 宣告性：你只需要宣告輸出，查詢引擎就會找出執行查詢的最佳方式。最佳化器，特別是1979年Pat Selinger等人發明的基於成本的最佳化器，幫助持續地改進效能。這為每個新進入者提供了一個很高的標準。最近一篇關於Apache Hive的論文就是一個複雜性和完善涉及的例子為什麼SQL如此成功？
   
2. SQL不僅用於“查詢”，還用於更新資料、執行事務。儲存過程，UDF透過將過程語言與宣告性SQL相結合來擴充套件訪問範圍。
3. SQL具有可塑性。它已經多次標準化，每次都會新增一本功能齊全的書，一個充滿語法的商店，以及一個充滿關鍵詞的詞典。當然，並非所有的SQL都是相同的。即使是RDBMS上的傳統SQL實現也不完全相容，除非您小心地編寫SQL使其相容。透過所有這些，SQL的原始精神得以保留。SQL的一個進化的例子是SQL++。Don Chamberlin和Mike Carey教授討論了支援複雜資料模型的需求，使使用者和開發人員可以輕鬆訪問JSON中的資料。Don寫的書《SQL++ for SQL users：A Tutorial》介紹了SQL++的最新發展，SQL++這種語言是為靈活的JSON資料模型上的資料處理而設計的，它保持了與SQL的相容。
4. 就像它所借用的英語一樣，SQL對新資料型別、訪問方法和用例的新思想和擴充套件持開放態度。
5. SQL與資料表示的獨立性使其可以用於非關係資料：CSV, JSON和所有大資料格式。有些人把關係模型表示的剛性和SQL的剛性混為一談。實際上，對於任何給定的Schema，SQL允許你對任何資料格式執行select-join-group-aggregate-project操作

評估SQL支援

既然SQL無處不在，那麼你就需要在支援級別上進行盡職調查。

1. 找出每個工作負載的特徵和目標。例如，互動式應用程式，或互動式分析，或批次分析，或BI工作負載等等。
2. 支援的宣告反映了操作能力。
3. 在表示式（標量、聚合、布林值）、聯接（內聯、左聯/右聯/全聯）、子查詢、派生表、排序和分頁（LIMIT / OFFSET）方面的語言能力。
4. 索引：沒有正確索引的SQL只是一個圖靈機器原型。
5. 最佳化器：查詢重寫，選擇正確的訪問路徑，建立最佳執行路徑是使得SQL語言成為成功的第4代語言的原因。有些具有基於規則的最佳化器，有些具有基於成本的最佳化器，而有些則兩者都有。評估最佳化器的質量至關重要。典型的基準（TPC-C、TPC-DS、YCSB、YCSB-JSON）在這裡對你沒有幫助。
6. 正如我們常說：“資料庫有三個重要方面：效能、效能和效能”。測量工作負載的效能很重要。YCSB和擴充套件的YCSB-JSON將使評估更容易。
7. SDK：豐富的SDK和語言支援，加快你的開發速度。
8. BI工具支援：對於大型資料分析，透過標準資料庫連線驅動程式來支援BI工具通常非常重要。

N1QL的建立者Gerald Sangudi曾經說過，SQL是成功的，因為它代表了資料處理的基本操作。SQL支援一組豐富的操作：select-join-nest-unnest-group-aggregate-having-window-order-paginate-set-ops。這是我們（或機器）在指定資料操作時的想法嗎？雖然還有待觀察，但像Python和Java這樣的語言正在為資料的這些操作新增運算子。也許，其他人也會效仿。SQL已經進入了關係型資料庫模型不曾涉足的領域。可以毫不誇張地說：

SQL已死，但SQL將永存！