我希望现代关系查询语言具备的特性

原文 ↗ Hacker News 讨论 ↗

SQL 笨拙的语法、较差的可组合性以及难以调试的行为，让许多工程师开始质疑它是否仍应作为查询关系数据的主流方式。评论者一方面权衡其无处不在的优势和久经考验的生态，另一方面也在讨论更新的想法，例如基于 Datalog 的系统、PRQL 风格的管道语法、实时/流式查询，以及语言集成或基于 IR 的方案，这些方案可以编译到 SQL 或更底层的核心表示。大语言模型进一步让局势复杂化：它们让从自然语言生成 SQL 变得更容易，从而减弱了改变现状的压力，但同时也降低了尝试全新查询语言的门槛。

SQL 的易用性与可组合性

  • 许多评论者认为 SQL 在认知上负担很重：不可组合、难以重构，而且不适合增量式构建查询。
  • JOIN 被描述为表达关系的一种“非自然”方式，尤其是与类似指针导航或图风格 API 的方式相比。
  • 也有人反驳，认为 SQL 语法很简单、广为人知，对 SQL 的畏惧更多是文化上的，而不是技术上的。
  • 隔离级别、锁行为以及优化器计划变化被视为主要痛点，而普通开发者往往很难理解这些问题。

ORM、原始 SQL 与工具链

  • ORM 因安全性（通过参数化抵御 SQL 注入）和更高层次的易用性而受到重视。
  • 批评者认为 ORM 会鼓励回避强大的 SQL 特性（CTE、窗口函数、分区、存储过程），并且可能隐藏事务陷阱。
  • 有些人主张让原始 SQL/存储过程更易于部署，把数据库更多地当作一个“可脚本化”的组件。
  • 将逻辑拆分在应用代码和存储过程之间进行调试，常常被描述为很痛苦。

LLM 与查询语言

  • 有一条观点认为 SQL 会变得像汇编语言：大多由工具/LLM 生成，因此语法上的抱怨会变得不那么重要。
  • 也有人反驳说，LLM 同样可以快速学习并设计新的语言和运行时，从而可能降低试验新方案的门槛。
  • 对于 LLM 在新语言上的表现是否会明显差于 SQL 这类高数据量语言，大家存在分歧。

替代方案与实验

  • Datalog 和基于 Datalog 的系统（例如 CodeQL、各种开源引擎）被反复提及，被认为更具可组合性和表达力。
  • 其他被提到的尝试包括：PRQL、图风格查询（GraphQL、Cypher）、面向 LLM 的紧凑查询语法、Mongo 风格的文档查询，以及向多种前端语言暴露 IR 的数据库。
  • 有些人将 SQL 与更“关系纯粹”的现有系统进行不利比较，认为 SQL 的主导地位是历史原因，而不是技术原因。

期望的改进

  • 为复杂 SQL 提供更好的错误信息和诊断。
  • 原生支持嵌套/关系结构，而不是平面表。
  • 实时/持续查询或流式增量，而不是反复轮询。
  • 列弃用警告、模式版本控制，以及更安全的模式演化。
  • 类型化、语言集成的查询，编译到共享的关系 IR，让不同语法能够共存。

采用与惯性

  • 要替代 SQL 被认为极其困难，因为：
    • 专业知识、工具和生态都以 SQL 为中心。
    • 新语言必须好得多，才足以证明迁移的合理性。
  • 有些人总结道，SQL 是“除了所有其他尝试过的方案之外最差的那个”，而许多尝试最终要么重新嵌入 SQL，要么随着时间推移增加 SQL 兼容性。