![]()
在 SQL 被引入的 45 年中，它經歷了許多數據庫的誕生和消亡，也經歷了許多數據處理方式的誕生和消亡。
![]()
作者 | Jennifer Ouellette
譯者 | 彎月
責編 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下為譯文：
四十五年前，兩位年輕的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 為何會成功？
聲明性：你只需要聲明輸出，查詢引擎就會找出執行查詢的最佳方式。優化器，特別是1979年Pat Selinger等人發明的基於成本的優化器，幫助持續地改進性能。這為每個新進入者提供了一個很高的標準。最近一篇關於Apache Hive的論文就是一個複雜性和完善涉及的例子為什麼SQL如此成功？
SQL不僅用於「查詢」，還用於更新數據、執行事務。存儲過程，UDF通過將過程語言與聲明性SQL相結合來擴展訪問範圍。
SQL具有可塑性。它已經多次標準化，每次都會添加一本功能齊全的書，一個充滿語法的商店，以及一個充滿關鍵詞的詞典。當然，並非所有的SQL都是相同的。即使是RDBMS上的傳統SQL實現也不完全兼容，除非您小心地編寫SQL使其兼容。通過所有這些，SQL的原始精神得以保留。SQL的一個進化的例子是SQL++。Don Chamberlin和Mike Carey教授討論了支持複雜數據模型的需求，使用戶和開發人員可以輕鬆訪問JSON中的數據。Don寫的書《SQL++ for SQL users：A Tutorial》介紹了SQL++的最新發展，SQL++這種語言是為靈活的JSON數據模型上的數據處理而設計的，它保持了與SQL的兼容。
就像它所借用的英語一樣，SQL對新數據類型、訪問方法和用例的新思想和擴展持開放態度。
SQL與數據表示的獨立性使其可以用於非關係數據：CSV, JSON和所有大數據格式。有些人把關係模型表示的剛性和SQL的剛性混為一談。實際上，對於任何給定的Schema，SQL允許你對任何數據格式執行select-join-group-aggregate-project操作
![]()
評估SQL支持
既然SQL無處不在，那麼你就需要在支持級別上進行盡職調查。
找出每個工作負載的特徵和目標。例如，交互式應用程序，或交互式分析，或批量分析，或BI工作負載等等。
支持的聲明反映了操作能力。
在表達式（標量、聚合、布爾值）、聯接（內聯、左聯/右聯/全聯）、子查詢、派生表、排序和分頁（LIMIT / OFFSET）方面的語言能力。
索引：沒有正確索引的SQL只是一個圖靈機器原型。
優化器：查詢重寫，選擇正確的訪問路徑，創建最佳執行路徑是使得SQL語言成為成功的第4代語言的原因。有些具有基於規則的優化器，有些具有基於成本的優化器，而有些則兩者都有。評估優化器的質量至關重要。典型的基準（TPC-C、TPC-DS、YCSB、YCSB-JSON）在這裡對你沒有幫助。
正如我們常說：「 數據庫有三個重要方面：性能、性能和性能」。測量工作負載的性能很重要。YCSB和擴展的YCSB-JSON將使評估 更容易。
SDK：豐富的SDK和語言支持，加快你的開發速度。
BI工具支持：對於大型數據分析，通過標準數據庫連接驅動程序來支持BI工具通常非常重要。
N1QL的創建者Gerald Sangudi曾經說過，SQL是成功的，因為它代表了數據處理的基本操作。SQL支持一組豐富的操作：select-join-nest-unnest-group-aggregate-having-window-order-paginate-set-ops。這是我們（或機器）在指定數據操作時的想法嗎？雖然還有待觀察，但像Python和Java這樣的語言正在為數據的這些操作添加運算符。也許，其他人也會效仿。SQL已經進入了關係型數據庫模型不曾涉足的領域。可以毫不誇張地說：
SQL已死，但SQL將永存！
【END】
