最近，小编刷到了这么一篇文章，引发了大家热议，网友表示：
“没有一个技术是万能的，放弃SQL现在又有什么完美解决方案吗？”
“就算SQL有一定的局限性，仍然避免不了大多数人去使用的，暂时还没有更好的替代品。”
“文章观点禁不住推敲。任何技术都是解决特定问题的，都有边界；SQL关系型数据库仍然是大多数OLTP数据库的主流选择。”
“就算要放弃SQL，但是在许多情况下，具备SQL技能仍然是有价值的，因为它在处理结构化数据方面非常强大和高效。”
以下是正文内容：
不过这些悖论并不重要，因为市场已经表明：时至今日，即使出现了不少更新的、更强大的选择，SQL还是许多人的首选。无论是小网站还是大公司，各地的开发人员都知道SQL。
SQL的表格模型占据主导地位，以至于许多非SQL项目最终都添加了SQL的接口，因为用户需要它。这甚至适用于NoSQL运动，尽管NoSQL的发明初衷是为了摆脱旧的范式。但最终，似乎还是SQL赢了。
大家都知道，SQL有一定的局限性，但这并不足以让人们彻底放弃它。开发人员可能永远不会起身将所有数据从SQL中迁移出去。但是SQL的问题是真实的，足以给开发人员带来压力，有时候甚至需要对某些项目进行重新设计。
下面是我们希望放弃SQL的9个原因，尽管我们心知肚明我们可能做不到。
SQL让事情变得更糟的9种方式：
表格无法缩放
SQL不是JSON或XML原生的
列集是一项耗费大量时间的工作
SQL不是实时的
JOINS是一个令人头疼的问题
列是对空间的浪费
优化器只是有时有用
非规范化将表视为垃圾
附带的想法会破坏你的数据库
一、表格无法缩放
关系模型喜欢表格，所以我们不断构建它们。这对于小型乃至普通大小的数据库来说都没问题。但这个模型要是用在真正的大型数据库上就会开始崩溃。
有些人试图通过将新旧数据库结合来解决这个问题，比如将分片集成到旧的开源数据库中。添加层似乎可以使数据更易于管理，并提供无限的规模。但这些增加的层可能隐藏地雷。根据分片中存储的数据量，SELECT或JOIN的处理时间可能会截然不同。
分片还迫使DBA考虑数据可能存储在不同的机器上，甚至可能存储在不同的地理位置上的可能性。缺乏经验的管理员在开始跨表搜索时，如果没有意识到数据存储在不同的位置，可能会感到困惑。模型有时会从视图中抽象出位置。
一些AWS机器配备了24tb的RAM。为什么?因为一些数据库用户需要这么多。他们在SQL数据库中有这么多数据，并且在一台机器上，在一块RAM中运行得更好。
二、SQL不是JSON或xml原生的
SQL在语言界可能是一种常青树，但它并不特别适合JSON、YAML和XML等较新的数据交换格式。所有这些都支持比SQL更分层、更灵活的格式。SQL数据库的核心仍然停留在关系模型中，表无处不在。
市场会想方设法掩饰这种常见的抱怨。使用正确的粘合代码添加不同的数据格式(如JSON)相对容易，但时间的损失不可避免，你要为此做好准备。
一些SQL数据库现在能够编码和解码更现代的数据格式，如JSON、XML、GraphQL或YAML作为本地特性。但是在内部，数据通常使用相同的旧表格模型进行存储和索引。
在这些格式之间转换数据要花费多少时间?用一种更现代的方式存储数据不是更容易吗?一些聪明的数据库开发人员继续进行实验，但奇怪的是，他们常常最终选择使用某种 SQL 解析器。
三、编组是一项耗费大量时间的工作
数据库可以在表中存储数据，而程序员编写处理对象的代码。设计数据驱动的应用程序的大部分工作似乎都是找出从数据库中提取数据并将其转换为业务逻辑可以处理的对象的最佳方法。然后，必须通过将对象中的数据字段转换为SQL upsert（即“update+insert”,“存在则更新，不存在则插入”）来解组数据。难道没有一种方法可以让数据保持随时可用的格式吗？
四、SQL不是实时的
最初的SQL数据库是为批处理分析和交互模式而设计的。具有长处理管道的流数据模型是一个相对较新的想法，它并不完全匹配。
主要的SQL数据库是在几十年前设计的，当时的模型设想数据库可以独立运行，而且可以像某种先知一样回答查询。有时他们反应迅速，有时则不然。这就是批处理的工作方式。
一些最新的应用程序要求更好的实时性能——不仅仅是为了方便，而且因为应用程序需要它。在现代的流媒体世界里，像静坐山间的大师那样岿然不动是行不通的。
专为这些市场设计的最新数据库非常重视速度和响应能力。它们不提供那种复杂的SQL查询，因为这种查询会让一切都迟滞下来。
五、连接是一个令人头疼的问题
关系数据库的强大之处在于将数据分解成更小、更简洁的表。烦恼也如影随形。
使用join动态地重新组装数据通常是作业中计算成本最高的部分，因为数据库必须处理所有数据。当数据开始超出RAM的容量时，令人头疼的事情就开始了。
对于学习SQL的人来说，连接可能会令人难以置信地困惑。弄清楚内部join和外部join之间的区别仅仅是个开始。寻找将多个join连接在一起的最佳方式会使情况变得更糟。内部优化器可能会帮上忙，但是当数据库管理员要求一个特别复杂的组合时，它们就无能为力了。
六、列是对空间的浪费
NoSQL的一个伟大思想就是让用户从列中解脱出来。如果有人想向条目添加新值，他们可以选择他们想要的任何标记或名称。不需要更新模式来添加新列。
SQL的拥护者在该模型中只看到混乱。他们喜欢表格自带的顺序，不希望开发人员即时添加新字段。他们有一定的道理，但是添加新列可能非常昂贵和耗时，特别是在大型表格中。将新数据放在单独的列中并使用join对它们进行匹配，无疑会耗费更多的时间，并增加复杂性。
七、优化器只是有时有用
数据库公司和研究人员已经花费了大量时间来开发出色的优化器，这些优化器可以分解查询并找到排序其操作的最佳方式。
收益可能是显著的，但是优化器所能做的是有限的。如果查询需要一个特别大或者特别繁复的响应，那么优化器不能只是说，“你真的确定吗?”它必须汇总答案，然后按照指令去做。
有些DBA只有在应用程序开始扩展时才知道这一点。早期的优化足以处理开发过程中的测试数据集。但在关键时刻，优化器无法从查询中榨取更多的能量。
八、非规范化将表视为垃圾
开发人员经常发现自己陷入了两难境地：一方面，想要更快的性能，另一方面精打细算，不想为更大、更昂贵的硬件付费。一种常见的解决方案是对表进行非规范化，这样就不需要复杂的连接或跨表操作。所有的数据都在一个长矩形中。
这不是一个糟糕的技术解决方案，而且它通常会有实效，因为磁盘空间已经变得比处理能力便宜。但是非规范化也抛弃了SQL和关系数据库理论中最聪明的部分。当数据库变成一个长CSV文件时，所有这些花哨的数据库功能几乎都消失了。
九、附加功能会破坏你的数据库
多年来，开发人员一直在为SQL添加新特性，其中一些功能非常酷。但不得不提的是，这些花哨的功能通常是附加的，可能会导致性能问题。
一些开发人员警告说，你应该特别小心子查询，因为它们会减慢所有操作的速度。另一些人则表示，选择像公共表表达式、视图或窗口这样的子集会使代码过于复杂。代码的创建者可以阅读它，但是其他人在试图保持SQL的所有层和代的清晰性时都感到头痛。这就像在看诺兰的电影，只不过是用代码写的。
有些附加功能已经妨碍了之前行之有效的做法。窗口函数的设计是为了通过加速计算结果(如平均值)来加快基本数据分析的速度。但是许多SQL用户会发现并使用一些附加的特性。在大多数情况下，他们会尝试新功能，然后当他们的机器慢如蜗牛时才会注意到有些问题。之后，他们会需要一些有经验的DBA来解释发生了什么以及如何修复它。
对于本文观点，你怎么看呢？欢迎评论区交流~
作者丨Peter Wayner 编译丨Noe
来源丨公众号：51CTO技术栈（ID：blog51cto）
原文地址丨https://www.infoworld.com/article/3711272/9-reasons-sql-has-got-to-go.html
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
