反对SQL与捍卫SQL的论战

Jamie Brandon在Against SQL发表了反对SQL：

首先他认为关系数据库好处是：

• 共享的通用数据模型允许以多种不同语言编写、在不同机器上运行并具有不同生命周期的程序之间进行协作。
• 规范化允许更新数据而不必担心忘记更新派生数据。
• 物理数据独立性允许更改数据结构和查询计划，而无需更改所有查询。
• 声明性约束清楚地传达了应用程序不变量并自动强制执行。
• 与命令式语言不同，关系查询语言没有由循环计数器和可别名指针创建的虚假数据依赖性。这使得关系语言：
• 非常适合现代机器。可以重新排列数据以获得更紧凑的布局，甚至是自动压缩。操作可以重新排序以获得高缓存局部性、管道友好的热循环、simd 等。
• 适合自动并行化。
• 适合增量维护。

但 SQL 是唯一广泛使用的关系模型实现，缺点是：

• 缺乏表现力：SQL 是一种特别缺乏表现力的语言。许多简单的类型和计算根本无法表达。结构是脆弱的——对计算的小改动可能需要对代码进行大的改动。
• 不可压缩：如果一个计算在多个地方使用，我们可以将它分配给一个变量，然后在这些地方使用该变量。或者，如果计算依赖于每个地方的不同输入，我们可以创建一个函数并将不同的输入作为参数传递。
• Non-porous：虽然单个数据库可以通过多种方式进行扩展，但扩展不能在数据库之间轻松共享，并且 SQL 规范仍然试图吞噬整个世界。

这些问题存在于我们用于访问数据的主导模型中，这一事实对整个行业产生了巨大的下游影响：

• 复杂性严重拖累了运行时和工具的质量和创新：因为 SQL 是如此缺乏表达、不可压缩和不可移植扩展，所以它永远无法开发一个库包生态系统。如果你开发一个新的 SQL 实现，你也必须从头开始实现整个生态系统，因为用户不能自己实现它。
• 需要在数据库和客户端之间进行手写协调的应用程序层使关系数据库的大多数最佳功能变得无用：关系数据库的最初想法是直接从客户端查询它们。随着网络的兴起，这个想法消失了——SQL 太复杂了，不能轻易地防止对抗性输入，SQL 查询的缓存失效太难了，并且没有办法轻松地产生后台任务；ORM 容易出现n+1 查询错误和野生并发。换句话说，它们不擅长高效查询数据，也不擅长利用事务——关系数据库的两个核心特性。
• GraphQL的成功表明这些痛苦是真实存在的，而且人们确实希望直接从客户端发出丰富的查询。与 SQL 相比，GraphQL 更容易实现，更容易缓存，攻击面更小，具有各种压缩常见模式的机制，易于遵循外键并返回嵌套结果，具有一流的交互机制外来代码和外部世界，拥有丰富的类型系统（有联合类型！），并且很容易嵌入到其他语言中。

我希望人们获得的核心信息应该是：通过替换 SQL可能会释放大量价值，更一般地说，是重新思考我们在数据库、查询语言和编程语言之间划清界限的位置和方式。

详细点击标题。

总结一下：

• SQL 语言中的设计缺陷导致语言没有库生态系统和限制创新的繁重规范。
• SQL 数据库接口中的其他设计缺陷导致将尽可能多的逻辑移至应用层，并限制了数据库最有价值功能的使用。
• 现在修复其中任何一个都可能为时已晚。

Pedram Navid捍卫SQL文章：

Jamie Brandon 反对 SQL 的宣言认为 SQL 很糟糕，而且糟糕到影响了整个行业。SQL 的问题归结为它的无表达性、不可压缩性和不可移植性。我的目标不是反驳他的观点，Jamie 的大部分论点都反对几乎没有人与之交互的语言部分，其余部分已经有了一些非常好的解决方案。我真正担心的是，它会阻碍人们学习 SQL，并使那些以 SQL 为主要语言的人感到不合适。

一般而言，软件工程中围绕数据存在一种持续的、不言而喻的光环。“软件工程”和“数据人员”之间几乎被划分为两个阶级。对于数据分析人员而言，分析数据很难：生态系统很难。数据很乱。很难测试。我们还没有找到正确的工具、正确的调试、正确的环境，甚至还没有找到正确的教学方法。

从事这项工作的人并不缺乏技能。他们使用的工具和语言也同样有用，因为它们没有其他语言的特性。他们对业务感同身受，并且有着无穷无尽的好奇心。数据人员是我见过的最聪明、最善良的人。

因此，虽然可能有人反对 SQL，但要知道我们中的许多人都非常支持 SQL。世界因它而变得更好。

关于SQL 的缺点在于“几乎没有人与之交互的语言部分”。来自分析师的分析正处于十字路口则也是反对SQL，认为SQL技术会阻碍排斥更具有分析思维的人才进入数据分析等软件工程行业：

Jamie 的原始帖子认为 SQL 不符合其他现代语言所做的许多标准；因此，根据 Jamie 的说法，建立在 SQL 之上的整个分析大厦存在无法弥补的缺陷。

Pedram 不同意其优点，称 SQL 的缺点在于“几乎没有人与之交互的语言部分”。我倾向于这个观点。我几乎每天都使用 SQL 近十年，我甚至不理解Jamie的许多担忧，更不用说对它们感到沮丧了。

分析师必须启动数据库、管理 Docker、运行 Python 环境、开发测试框架，并维护一个由不匹配的内部工具和第三方应用程序组成的脆弱的 Rube Goldberg 机器。Pedram 认为，这可能看起来不像传统的软件工程，但它是工程，很难，而且不能被忽视。

这是事实，但Pedram回避了更基本的一点：分析主要不是技术性的。 虽然技术技能很有用，但它们并不是普通分析师与优秀分析师的区别。当有人质疑我们是否是真正的工程师时，我们不应该觉得有必要拿出我们的技术证书。我们应该说，“那又怎样？那不是我们的工作。”

如果我哥哥 Will 申请硅谷的数据分析师工作，他会立即被拒绝。他的简历上的任何内容都不会引起招聘人员注意：他拥有法律和历史学位，而不是 STEM；他熟悉 Excel，而不是 Python 或 SQL；他是一个分析性的思考者，但不符合如大多数科技公司职位列表的技术参数所定义的分析师。

然而，如果他想要从事这样的职业，他会和我们任何人一样擅长。他是全国领先的城市人口学专家之一，这个主题比几乎任何行业关注的问题都更加结构化和数量上复杂。他经常使用比最杂乱无章的公司数据库还要混乱和繁琐的政府数据源。尽管为一个距离华盛顿特区一千英里的相对默默无闻的组织工作，他通过看到其他人看不到的东西，尤其是通过更好地描述这些想法而在美国政治的“话语”中赢得了一席之地。

考虑到一个细微的问题需要敏锐的眼光、分析的头脑和有说服力的笔来推荐具体的解决方案，我哥哥是一个完美的人选。

正如 Pedram 所暗示的那样，用技术术语定义分析师会将人们排除在他们有资格从事的领域之外。

banq总结：SQL与分析思维是两种不同技能，SQL技能可以短时间学习培养，分析思维培养确实很难，对复杂系统的洞察力和直觉有时和数学能力一样几乎是天生的，而且是跨行业的，如何吸引更优秀人才进入互联网或计算机软件工程行业，也许SQL是一个障碍。

反对SQL与捍卫SQL的论战