好吧我承认我有标题党+软文的目的性，但是我真的把 39 页的主题（和少部分内容）都看了一遍，看到节点里那么多 PingCAP 的文章，我觉得我应该也行（？），毕竟我还是想要正儿八经讨论一下 SQL 本身的。

背景：10+ 年 Python 工程师，七七八八各种方向都做过，一直对 SQL 在应用开发——尤其是快速迭代的项目——中的使用方式有一些徘徊不定：

• 手写 SQL 本身没毛病，但是集成到应用中要写一大堆多余的代码；
• ORM 大多封装的太隐秘了，再加上在几个项目中被坑到过，总体持批评态度；
• Query builder 能解决大部分的问题（ schema 定义、查询组装和重用、生成 SQL ），但是最后临门一脚没法封装成业务对象，还得包一层；
• 2017 年有机会（ asyncpg 当时没有合适的 ORM ）用 SQLAlchemy 的 query builder 自己做了一个 ORM （GINO），加了一个业务对象 loader 功能；
• 至此感觉在 SQL 和应用程序之间的这些乱七八糟，基本上就都是这样的了：大部分时间够用了，能提高开发效率；但是啰里啰嗦一大堆，并且关键时候你还是得特别清楚整个技术栈是怎么运行的，该优化 SQL 的时候照样跑不了。
• 中间肯定各种 NoSQL 也折腾过，在芝大还试用了 Graph 数据库，也做过 GraphQL API 。感觉各有所长，能在特定场景下发挥优势，但回到普罗大众的项目，还是关系模型最合适常规数据。

直到 2021 年换到现在的工作，最近翻译了一篇老板写的博客《 We Can Do Better Than SQL 》，才感觉这些其实都是 SQL 的锅——关系模型是好模型，但被 SQL 这个交互层的接口给搅乱了。当然这里不是说 SQL 一无是处，毕竟现在如此广泛的应用，说明它是十分成功的，必然有其可取之处，类比 PHP 、JavaScript 或者 MySQL （手动大狗头怕是也难以保命了的那种）。

这篇文章固然是在介绍我现在正参与开发的新开源数据库 EdgeDB，但是文中吐槽 SQL 的几个角度还是很有趣的，尤其 NULL 那一块 JavaScript 看了都自愧不如。我简单总结如下，供大家讨论：

1. 正交性问题。

   大概就是说，SQL 语句很难写，特殊情况特别多，基本上没法做语句组合。

2. 不够紧凑。

   关键词有 469 个之多，这还只是 PostgreSQL 实现了的部分。就是不太像一门编程语言，比较啰嗦。

3. 语言设计不一致。

   NULL 的槽点都在这里，总结来说就是惊喜不断，碎片化也堪忧。如果没有 ORM 的保驾护航，萌新很容易踩坑。

谈及原因，主要说的就是，SQL 最一开始设计的是给非技术人员创建报表用的，人家没想着你能嵌到程序里这个玩法呀，怎么能设计出对工程师友好的语言呢。再加上资本主义的毒瘤把控了标准的制定，IBM 和 Oracle 互相攀比，没心情照顾使用者，有什么就用什么了。反正就是 SQL 到现在已经是这样了，大家也都习惯了，关系模型还得用，也就很少有人会去想搞一个新的语言出来。

在后面就是 EdgeQL 的介绍了，主要集中在怎么让开发人员爽。我就不多介绍了，有兴趣请自行阅读。

还是回到主题，关于 SQL 的问题，同学们怎么想？确实影响开发效率和心智吗？以后 SQL 会不会像 C 语言一样，虽然仍是 IT 行业的基石，但很多新项目就会用 Rust 、Swift 、Go 这样的现代语言来开发了吗？查询语言这波能起来吗，要跟吗？