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 是基于关系代数的基础，目的是通过提供一个类似于英语的查询语言来更简单地实现以下目标：
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 将永存！