是一个悖论研究。SQL可能笨拙而冗长，但开发人员经常发现它是提取所需数据的最简单、最直接的方法。当查询写入正确时，它可以像闪电一样快，而当查询出错时，它 几十年，但新功能一直在不断增加。

这些矛盾并不重要，因为市场已经表明 SQL是许多人的首选，即使有更新的、更强大的选项。从最小的网站到最大的大型公司，各地的开发人员都知道SQL。他们依靠它来组织所有的数据。

，以至于许多非SQL项目最终都添加了SQLish接口，因为用户需要它。 发明是为了摆脱旧的范式

将所有数据从SQL中迁移出去。但是SQL的问题是真实 的，足以给开发人员带来压力，增加延迟，甚至需要对某些项目进行重新设计。

下面是我们希望放弃SQL的9个原因，尽管我们知道

表格不能扩展

。这对于小型甚至正常大小的数据库来说

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

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

因为一些数据库用户需要这么多。他们在SQL数据库中有这么多数据，

SQL不是JSON或XML原生的

的语言，但它并不特别适合JSON、YAML和XML等较新的数据交换格式。所有这些都支持比SQL更分层、更灵活的格式。SQL数据库的核心仍然停留在关系模型中，

市场会想方设法掩盖这种常见的抱怨。使用正确的粘合代码添加不同的数据格式 相对容易，但您将付出损失时间的代价。

一些SQL数据库现在能够编码和解码更现代的数据格式 特性。但是在内部，数据通常使用相同的旧表格模型进行存储和索引。

在这些格式之间转换数据要花费多少时间 用一种更现代的方式存储数据不是更容易吗 一些聪明的数据库开发人员 继续进行实验，但奇怪的是，他们经常会使用某种SQL解析器。

封送（Marshaling）是一项耗费大量时间的工作

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

SQL并非实时的

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

主要的SQL数据库是在几十年前设计的，当时的模型设想数据库可以独立运行，像某种 们反应迅速，有时则不然。这就是批处理的工作方式。

一些最新的应用程序要求更好的实时性能 不仅仅是为了方便，而且因为应用程序需要它。在现代的流媒体世界里，

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

JOIN是一个令人头疼的问题

关系数据库的强大之处在于将数据分解成更小、更简洁的表。

使用JOIN动态地重新组装数据通常是作业中计算成本最高的部分，因为数据库必须处理所有数据。当数据开始超出RAM时，

对于学习SQL的人来说，JOIN可能会 困惑。弄清楚内部JOIN和外部JOIN之间的区别仅仅是个开始。寻找将多个JOIN连接在一起的最佳方式 。内部优化器可能会帮上忙，但是当数据库管理员要求一个特别复杂的组合时，它们就无能为力了。

列（Column）是对空间的浪费

的一个伟大思想就是让用户从列中解脱出来。如果有人想向条目添加新值，他们可以选择他们想要的任何标记或名称。不需要更新模式来添加新列。

SQL捍卫者在该模型中只看到 混乱。他们喜欢表自带的顺序，不希望开发人员匆忙添加新字段。他们有一定的道理，但是添加新列可能非常昂贵和耗时，特别是在大型表中。将新数据放在单独的列中并使用JOIN对它们进行匹配会增加更多的时间

优化器并非始终有用

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

收益可能是显著的，但是优化器所能做的是有限的。如果查询需要一个特别大的或 的响应，那么优化器不能只是说， 它必须把答案集合起来，然后按照指令去做。

只有在应用程序开始扩展时才 这一点。早期的优化足以在开发期间处理测试数据集。但是在关键时刻，优化器

反范式化（Denormalization）将表视为垃圾

想要更快性能的用户和不想为更大、更昂贵的硬件付费的 用户，开发人员经常处于两难境地 。一种常见的解决方案是对表进行 ，这样就不需要复杂的JOIN或跨表操作。

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

附加特性会破坏数据库

多年来，开发人员一直在为SQL添加新特性，其中一些非常 可能会导致性能问题。一些开发人员警告 您应该特别小心子查询 ，因为它们会减慢所有操作的速度 选择像公共表表达式、视图或Windows这样的子集会使代码过于复杂

的设计是为了通过加速计算结果 来加快基本数据分析的速度。但是许多SQL用户会发现并使用一些附加的特性。在大多数情况下，他们会尝试新功能，只有当他们的机器慢得像爬行一样时才会注意到 问题。然后他们会需要一些 来解释发生了什么以及如何修复它。

原文标题： 9 reasons SQL has got to go ，作者：Peter Wayner