SQL 是关系代数的语法糖

原文 ↗ Hacker News 讨论 ↗

SQL 的整体看法

  • 使用广泛且功能强大，但许多人认为其语法杂乱、不一致，而且“反着来”，尤其是 SELECT 在前、FROM 在后的顺序，以及奇怪的作用域规则。
  • 也有人觉得它相当容易学习、表达力强，并且比基于 JSON 的或专有的查询语法更可取；对很多人来说，问题更多出在糟糕的模式设计和误用，而不是 SQL 本身。
  • 与 C 类比：值得深入了解，但有些人更偏好“受管理”的抽象；批评者则反驳说 ORM 存在泄漏，而且往往能力不足。

语法、易用性与工具

  • 抱怨点包括：解析顺序不直观、读取复杂嵌套查询困难、因为数据源出现在投影之后导致自动补全很难，以及像 DELETE FROM 这类没有保护措施的危险命令。
  • 缓解方式：使用 CTE、表值函数、临时表、事务，以及客户端安全措施（要求 DELETE 必须带 WHERE、特殊标志位）。
  • 排版、注释和 ER 图被视为维护复杂 SQL 的关键。

关系代数、理论与标准

  • 许多人同意，SQL 并不是关系代数上干净的语法糖：多重集与集合、NULL 语义、排序，以及许多“非关系的小玩意儿”都说明了这一点。
  • 对 Codd 的关系模型、谓词演算、Datalog、MonetDB 的 IR，以及《Third Manifesto》的引用，都体现了人们希望语言更接近形式化关系理论的愿望。
  • 有些人认为 SQL 标准过于复杂，实际上成了一道护城河，提高了新数据库实现的门槛。

替代方案与相关语言

  • 提到的替代或补充方案包括：PRQL、XTQL、LINQ 风格的查询表达式、Malloy、CozoDB、数据框库（Pandas、Polars、Ibis），以及 D 风格语言（尽管没有流行实现）。
  • 这些方案通常提升了可组合性、从左到右的可读性，以及与宿主语言的集成，但通常缺少完整的 DML 支持、特定厂商特性或成熟度。

学习、教学与实践

  • 有几位提到自己用了好几年才“真正理解” SQL，往往是在性能密集型或大规模工作触发之后。
  • 形式化的数据库教育并不均衡；有些人批评过于理论化的教学（包括一些关系理论教材），也有人称赞入门读物和实践性设计书籍易于理解。
  • 一个强烈的主题是：理解关系理论和良好的模式设计会极大改善 SQL 的使用体验，但 SQL 的缺陷仍然限制了设计良好的 RDBMS 引擎能够暴露的能力。