SQL 必须被淘汰的 9 个理由

尽管 SQL 很受欢迎并取得了成功，但它仍然是一项悖论研究。它可能笨重且冗长，但开发人员经常发现它是提取所需数据的最简单、最直接的方法。当查询编写正确时，它可能会快如闪电，而当查询未达到目标时，它会慢得像糖蜜。它已经有几十年的历史了，但新功能仍在不断增加。

这些悖论并不重要，因为市场已经表明：SQL 是许多人的首选，即使有更新且可以说更强大的选项。世界各地的开发人员（从最小的网站到最大的大型企业）都了解 SQL。他们依靠它来组织所有数据。

SQL 的表格模型占据主导地位，以至于许多非 SQL 项目最终都添加了 SQLish 接口，因为用户需要它。 NoSQL 运动也是如此，它的发明是为了摆脱旧范式。最终，SQL 似乎获胜了。

SQL 的限制可能还不足以将其扔进垃圾箱。开发人员可能永远不会将所有数据从 SQL 中迁移出来。但 SQL 的问题足够真实，足以给开发人员带来压力、增加延迟，甚至需要对某些项目进行重新设计。

以下是我们希望退出 SQL 的九个原因，尽管我们知道我们可能不会这样做。

SQL 让事情变得更糟的 9 种方式

表格无法缩放

关系模型喜欢表，所以我们不断构建它们。这对于小型甚至普通大小的数据库来说都很好。但在真正大规模的情况下，该模型开始崩溃。

有些人尝试通过将新旧结合起来来解决问题，例如将分片集成到旧的开源数据库中。添加层似乎可以使数据更易于管理并提供无限的规模。但这些增加的层可以隐藏地雷。 SELECT 或 JOIN 的处理时间可能截然不同，具体取决于分片中存储的数据量。

分片还迫使 DBA 考虑数据可能存储在不同机器甚至不同地理位置的可能性。如果没有意识到数据存储在不同的位置，那么开始跨表搜索的经验不足的管理员可能会感到困惑。该模型有时会从视图中抽象出位置。 

某些 AWS 计算机配备24 TB RAM。为什么？因为有些数据库用户需要这么多。他们在 SQL 数据库中拥有如此多的数据，并且在一台机器的一块 RAM 中运行得更好。

SQL 不是 JSON 或 XML 原生的

SQL 作为一种语言可能是常青树，但它与 JSON、YAML 和 XML 等较新的数据交换格式的配合并不是特别好。所有这些都支持比 SQL 更分层、更灵活的格式。 SQL 数据库的核心仍然停留在表无处不在的关系模型中。

市场找到了掩盖这种普遍抱怨的方法。使用正确的粘合代码添加不同的数据格式（例如 JSON）相对容易，但您会为此付出时间损失的代价。

一些 SQL 数据库现在能够将 JSON、XML、GraphQL 或 YAML 等更现代的数据格式作为本机功能进行编码和解码。但在内部，数据通常使用相同的旧表格模型来存储和索引。

将数据转入或转出这些格式需要花费多少时间？以更现代的方式存储我们的数据不是更容易吗？一些聪明的数据库开发人员继续进行实验，但奇怪的是，他们常常最终选择使用某种 SQL 解析器。这就是开发人员所说的他们想要的。

编组是一个很大的时间消耗

数据库可以将数据存储在表中，但程序员编写处理对象的代码。设计数据驱动应用程序的大部分工作似乎都是找出从数据库中提取数据并将其转换为业务逻辑可以使用的对象的最佳方法。然后，必须通过将对象中的数据字段转换为 SQL 更新插入来对它们进行解组。难道没有办法让数据保持随时可用的格式吗？

SQL 不实时

最初的 SQL 数据库是为批量分析和交互模式而设计的。具有长处理管道的流数据模型是一个相对较新的想法，并且并不完全匹配。

主要的 SQL 数据库是几十年前设计的，当时的模型设想数据库独立运行并像某种预言机一样回答查询。有时他们反应很快，有时则不然。这就是批处理的工作原理。

一些最新的应用程序需要更好的实时性能，不仅是为了方便，而且是因为应用程序需要它。在现代的流媒体世界中，像大师一样坐在山上并不那么有效。

专为这些市场设计的最新数据库非常重视速度和响应能力。他们不提供那种会减慢一切的复杂 SQL 查询。

JOIN 是一个令人头疼的问题

关系数据库的强大之处在于将数据分割成更小、更简洁的表。头痛随之而来。

使用 JOIN 动态重新组装数据通常是工作中计算成本最高的部分，因为数据库必须处理所有数据。当数据开始超出 RAM 的容量时，令人头疼的事情就开始了。

对于学习 SQL 的人来说，JOIN 可能会令人难以置信的困惑。弄清楚内部 JOIN 和外部 JOIN 之间的区别仅仅是一个开始。寻找将多个 JOIN 连接在一起的最佳方法会使情况变得更糟。内部优化器可能会提供帮助，但当数据库管理员要求特别复杂的组合时，它们无能为力。

列浪费空间

NoSQL 的伟大想法之一是让用户摆脱列的束缚。如果有人想向条目添加新值，他们可以选择他们想要的任何标签或名称。无需更新架构即可添加新列。

SQL 维护者只看到该模型中的混乱。他们喜欢表格附带的顺序，并且不希望开发人员即时添加新字段。他们说得有道理，但添加新列可能非常昂贵且耗时，尤其是在大表中。将新数据放在单独的列中并将它们与 JOIN 进行匹配会增加更多的时间和复杂性。

优化器只是有时有帮助

数据库公司和研究人员花费了大量时间来开发优秀的优化器，这些优化器可以分解查询并找到排序其操作的最佳方式。

收益可能很大，但优化器的作用有限。如果查询需要特别大或华丽的响应，优化器不能只是说“你真的确定吗？”它必须汇总答案并按照指示执行。

一些 DBA 仅在应用程序开始扩展时才了解这一点。早期的优化足以处理开发过程中的测试数据集。但在关键时刻，优化器无法从查询中榨取更多的能量。

非规范化将表视为垃圾

开发人员经常发现自己陷入了两难境地：想要更快性能的用户和不想为更大、更昂贵的硬件付费的精算师。一个常见的解决方案是对表进行非规范化，这样就不需要复杂的 JOIN 或跨表的任何内容。所有数据都已经存在于一个长矩形中。

这不是一个糟糕的技术解决方案，而且它常常会获胜，因为磁盘空间变得比处理能力更便宜。但非规范化也抛弃了 SQL 和关系数据库理论中最聪明的部分。当您的数据库变成一个长 CSV 文件时，所有这些花哨的数据库功能几乎都消失了。

附加的想法可能会破坏你的数据库

多年来，开发人员一直在向 SQL 添加新功能，其中一些功能非常聪明。您很难对不必使用的炫酷功能感到不安。另一方面，这些附加功能通常是用螺栓固定的，这可能会导致性能问题。一些开发人员警告说，您应该对子查询格外小心，因为它们会减慢一切速度。其他人则表示，选择公共表表达式、视图或 Windows 等子集会使代码变得过于复杂。代码的创建者可以阅读它，但其他人在试图保持 SQL 的所有层和生成的直线性时都会感到头疼。这就像看一部克里斯托弗·诺兰的电影，但是是用代码编写的。

其中一些伟大的想法妨碍了已经行之有效的做法。窗口函数旨在通过加快平均值等结果的计算来加快基本数据分析的速度。但许多 SQL 用户会发现并使用一些附加功能。在大多数情况下，他们会尝试新功能，只有当机器速度慢得像爬行一样时才会注意到出现问题。然后他们需要一些老的、灰色的 DBA 来解释发生了什么以及如何修复它。

作者：Peter Wayner