你认可吗 SQL必定隐没的九个理由

是一个悖论钻研。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