浏览了数据库节点所有 39 页的主题，为什么没见有人吐槽 SQL？

[fantix]

好吧我承认我有标题党+软文的目的性，但是我真的把 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 这样的现代语言来开发了吗？查询语言这波能起来吗，要跟吗？

[Chad0000]

10+C#工程师，手写 SQL 很多年，后面入轻量级 orm+部分手写 SQL ，最后入 ef ，基本上不需要写 SQL 了。爽。

SQL 对于我来说以前没什么问题因为主要使用 SQL server ，现在自己的项目很多切到了 MySQL 就有点烦恼了：每家支持不一样，比如最简单的分页，拼接字符串，比较烦。还好平时使用比较少。

[documentzhangx66]

很多高手在他们学习 SQL 的阶段，就已经吐槽过 SQL 了，这类帖子在 CSDN 的历史文档里应该有一部分。

SQL 不好用，主要是历史与生态问题，再抽象一点就是钱的问题。

如果你有足够的资金，你完全可以去找大佬设计更好的语言来替代 SQL ，并且推广下去。

[charlie21]

“xxx 太难用了” 的通用问题的解决办法就是外包一层继续用。在牺牲了一些指标的情况下是可以解决表面问题的。有钱有闲的巨佬才会去从根本解决问题，可能会长远获益 可能是 just another nice try 。

编程语言或者是电脑程序运行方式本身是有巨大倾向让人们去选择 “外包一层解决问题 即使代价是牺牲某些指标” 这种方式来只解决表面问题的。改变历史遗留问题的工作量会导致历史遗留情况很顽固 /人们对改变历史遗留情况的决心很低 而历史遗留问题又会影响未来选型，搞得就像 “谁出生得早 谁胜利” 而谁本身是一个凑合用的货 软件界好像就是这样

[charlie21]

一个软件的成功是什么？能不能成功，不仅仅是看它在普罗大众里的流行度。

把软件卖出去，就能有研究经费，就能继续研究。这个看能不能幸运地服务到一些大客户吧，大客户可能会懂得赏识这个。大客户要么不乐意牺牲关键指标，要么有自己的特殊需求。大客户的服务者可以是 “世间不容我 我闷声发大财”，甚至有可能做得好了直接被大客户百万美元收购。

一个软件的成功（的判定），不仅是普罗大众流行度得出的，也可以是由 “把自己置于一个卖方市场总是会比把自己置于一个买方市场好一些的” 而得出的

[mizuhashi]

其实 rails 的 activerecord 以外的 orm 都不算 orm

[murmur]

×select * from ... where
√dangerouslySetInnerHtml
比啰嗦 sql 还不配，基础关键字都挺简单的

[yulon]

所以不是有人发明了 NoSQL 吗，都已经变成事实标准了谁还天天去吐槽，知乎上都有一大堆吐槽，想看搜就行了

[cmdOptionKana]

NoSQL 和 GraphQL 之类的，就是在这样的背景下诞生的呀。SQL 的问题早就有过很多讨论了。

[sagaxu]

NoSQL 使用体验更烂，所以兼容 SQL 查询成了卖点

[sadfQED2]

@yulon 用过 mongo ，用过 es ，比 SQL 难用多了，而且 es 自己也发现了，现在 es 官方在推 sql 查询

[liprais]

看到资本主义毒瘤就懒得看了
书读的不多想的太多

[shakoon]

我做过近十年的 ETL ，中途也写过 JAVA ，经常写 SHELL ，不得不说 SQL 实在是很简单的一门语言了，很难有这种和自然语言这么相近还高效的编程语言了，而且熟练之后任何 ORM 都觉得难用，能手写 SQL 解决的东西绝不放到应用里去搞。楼主说的关键词多，但是 90%的关键词的使用概率是低于 10%的。NULL 的问题是问题也不是问题，要注意的地方无数前人已经总结成册，稍加学习就能搞定。

[fantix]

@Chad0000 @charlie21 嗯嗯，嗯！对，有道理！感谢分享！
@cmdOptionKana GraphQL 只能算是接口 spec 吧，感觉离查询语言还是稍有距离。NoSQL 们怎么说的，不太好一概而论，各自都有擅长解决的问题，不过确实没有能看到充分替代关系模型的解决方案。

[loginv2]

我倒是想用更好的，可我不会做也不懂设计，还能咋办

[fantix]

@loginv2 是我软文写得太软了吗？ EdgeDB 了解一下！声明式 schema 、内置 migration 、完备周边配套设施（客户端、CLI 以及现代开发工作流），最重要的是有杀手锏 EdgeQL ，一次性解决 SQL 各种顽疾，当天即可下地走动。

[Itoktsnhc]

EdgeQL 能有类似兼容层在现有的主流 RDBMS 上使用吗？如果只能对 EdgeDB 使用，那和 Cassandra 的 CQL ，同属于只特定一个 DSL 。这样其实更应该推广的是 EdgeDB?

[Itoktsnhc]

其实看 Hadoop 这一系列的发展，从一开始的谁也不爱，到最后的花式蹩脚支持 SQL ，可能证明业界大家就认这口？
凑合过呗 还能离咋地

[fantix]

@Itoktsnhc 啊对的，目前确实在推 EdgeDB ，但我确实有（特别长远不切实际的）想法，如果 EdgeDB 能被市场接受，那就回去攒人用 Rust 写一个咱自己的 EdgeQL 后端。关于兼容层，EdgeDB 作为 EdgeQL 的唯一实现，虽然有 IR ，但后端是强依赖于 Postgres 的，可以用 RDS Aurora 什么的，但再别的就不行了。

[fds]

支持！就是没有掘金账号没法点赞……
另外发布会有点儿早，能否在结束后将录像搬运到 B 站呢？

现在公司有时就将关系型数据库当 KV 数据库用呢，有些逻辑可能直接用程序代码里写了，非常丑陋。还是处在能用就行的温饱阶段。

[fantix]

@fds 感谢！我会动员全家老小尽快制作中文字幕发 B 站的。你后面碰到的这种情况怎么说的，纯粹实用角度可能也没毛病，有时候只能是自己怀揣一颗追求技术的心，把眼前的事情做完再说。但总感觉如果都这样的话，有点劣币驱逐良币的意思……

[cyspy]

OLAP 数据分析场景 SQL 还是没有对手，表达能力和可读性其实平衡得非常好。微服务下简单逻辑确实不如 API

[adoal]

看标题就想到了 EdgeDB ，没想到居然是开发者的贴

[adoal]

@fantix 用 Rust 自己轮一个后端感觉不是很有必要，毕竟 PG 的“后端”已经足够强大和成熟，而且 EdgeDB 针对的主要痛点不是后端，而是前端。不如（假如你们团队能搞定 PG 上游的话）对 PG 重新做架构，把语言 parser 和网络协议 listener 都解耦出来，语言上想用 SQL 用 SQL ，想用 EdgeQL 用 EdgeQL ，网络协议上想用 PG wire 用 PG wire ，想用基于 HTTP 的就用基于 HTTP 的……

[FrankHB]

主要的背景问题是“数据库”自己就有一大坨槽点，所以相比之下 SQL 的（早就被周知的）宏观问题都可以被忽略了。
现有的 DB 专业黑话其实跟 DB 的原始主要目的——抽象地管理持久的、规模化的数据——没多大关系。
说白了，要实现好“增删改查”这种表面上最 low 东西，反而是整体 DB 的共性。但是这里相对简单的实现却被其它玩意儿——比如文件系统——抢走了，剩下搞 DB 又不愿意反攻抢回饭碗，反而在另外的领域（什么关系模型什么查询语言这些本来就跟 DB 没什么必然联系的东西）不务正业。（题外话，FS 是更不成气候抽象破碎历史包袱一团糟的领域，我是支持 DB 抢回阵地然后把 FS 这整个领域从业界开除出去到只有 history interest 的，但是现在的习惯和分工嘛……DBA 该干什么呢？）
这些做法，即便的确能实现 DB 的一部分原始目的，充其量也就是一类实现方案而已。
具体举例，RDBMS 的滥用就是一大顽疾。（ ORM 是跟 RDB 八字不合的 OO 滥用的杂交产品，算是个直接副作用的典型例子。）实际上很多场景应用的设计方案从来就不需要引入这些这些 R （进一步，domain model 里根本不该有什么 table 应该长什么样之类的问题，或者说 table 这种数据结构都算不上是个 primitive 的 building block ），所谓“关系模型最合适常规数据”也就是潜意识把 RDB 太不擅长处理（连强上 RDBMS 都没法形成业界习惯）的数据和应用场景踢出这个领域以后的胡话而已。
而所谓 query language ，说白了就是 LP(logical programming) 的一个下位应用。这个领域作为大部分用户追求“看起来怎么好用就怎么设计”的 DSL ，长期处于专业人士（ PL 专家）爹不疼娘不爱的境地，就算再有 profit 也是应用上的脏活杂活，混成这样毫不奇怪。
LP 和 declarative language 的公共问题都拎不清楚，反过来要算账自然更加糊涂。

[fantix]

@adoal 哈，感谢关注！能改 pg 固然是一条捷径（相对于自己轮），然而工作好像也不少，EdgeQL 的 parser 后面还有一个编译器，通过 EdgeQL schema 上下文输出 SQL ，改到 pg 里这块要么输出 SQL AST 然后进 pg 后续的编译 planner 什么的继续跑，要么就得再多解耦 pg 的一些部分，然后重写 EdgeQL 编译器输出 pg 的命令，还得适配 planner 什么的。感觉前者就是用 C （或 Rust ）重写了现在的一些 Python 代码，和并进 pg 进程里，后者除了“存储引擎”基本上都是自己写了，所以还是想自己轮。嗨，这都是我自己瞎 yy ，就算重写也得找数据库大牛来撑，再说 EdgeDB 能发展到什么程度还说不定呢。

[FrankHB]

@charlie21 不清楚这里所谓“编程语言或者是电脑程序运行方式本身的”具体是指的什么，但这里看来是指向后兼容。
不好意思，这锅编程语言或者电脑程序都不背。
抽象未必保证封装和信息隐藏，更不直接保证可用性。是否要拆开现有的抽象设施是否包一个间接层取决于用户自己。
如果一个基础设施鼓吹的是“祖宗之法”，那决定选型的用户就该背锅。
该背锅的普遍不背锅，想甩锅的跑不掉，那就得自己反思行业问题了。

[fantix]

@FrankHB 老哥，您这高度拔得有点儿忒高了，完全超过了我能回复的范畴了……待我翻译成英文给我们老大看看。你的大意是不是说，现在的 DBMS 有些剑走偏锋了，无法把控好诸如文件系统级别的实现，虽然也能通过关系模型实现出基本能用的 RDBMS ，但始终还是没有能完整服务好原始需求，至于 LP 则更是没人关心，更别提很多 DBMS 连 DL 都没有（ EdgeDB 至少有 DDL ），所以发展成现在这样不足为奇，但也无能为力，因为要实现理想中的 DB ，还需打破现有技术的束缚——我不知道怎么说——按需求从比如 SSD 或 CPU 架构特性着手，技术栈从下往上一直堆到 DSL 层面的逻辑数据定义和操作语言，做出一个适用性更好的 DBMS ？

[fantix]

打错了，EdgeDB 至少有 SDL ，declarative schema definition language

[fds]

@FrankHB 醍醐灌顶呀。让我回想起了 https://en.wikipedia.org/wiki/WinFS ，当时还挺期待微软做出来，结果取消了。

[FrankHB]

关于 query language 的发展，自顶向下的角度上，我现在不大看好短期（近十年尺度上）的进展。
除了 LP 方面的固有问题长期兴趣不足（所以搞 DB 的基本自己玩）外，PL 还有更大的系统性问题——大部分搞工业 PL 欠缺专业性，很多又在忙于推销产品抢占市场（包括 HR 市场），自己都未必清楚在搞啥。而研究理论自己又在玩自己的，搞工业语言的又喜欢搞 pointer analysis 这种形而下的实现问题，连现有通用 PL 的普遍设计问题都没帮上多少忙，就更别提 DSL 了。
上面工业 PL 的问题也包括现役主力通用工业语言。有些缺陷是有广泛全局影响且对用户是非常明显的，但就是长期来没法解决。
举个例子：C 和 C++ 等语言的标准库所谓的 I/O ，根本就跟真正的 Input/Output 没多大关系；事实上语言规范描述标榜 I/O 的 API 的功能的很大篇幅都溜号到“格式化”上了。然而格式化其实是数据转换，关键是这其实是一种纯计算，跟 I/O 关注的问题很大程度上根本是对立的。那么讨论真 I/O 的工作在哪呢？嗯……比如“网络库”……（不知道 C++26 能不能塞个实际能用的进去。）（ Disclaimer：当然这不是说这里的数据转换不重要；并且，要实现好这些功能需要相当专业的技能，有的还非常困难。例如，一般来说，不能指望任意一个合格的工业界程序员在不参考已有实现的情况下独自把 dtoa 这样的操作实现得正确——注意这还仅仅是实用意义上的功能正确，不限定任务时间和不要求限定实现的可移植性及性能需求；不信邪对工程水平有自信的，可以自己试试实现，体验一下会踩些什么坑。）
拿 I/O 举例是因为这对通用 PL 来说是一个普遍重要的直接应用领域：没法描述 I/O 的语言不能向反馈有意义的计算作用(computational effect) ，是没有实用性的。然而传统学术意义上 PL 研究这些年显著流行的是 PFP(purely functional programming) ，根本上就是在折腾更烂的二等设计（比如 monadic interface ），而回避如何在现有基础上更好地抽象这些功能的基础设计问题。也就最近几年 algebriac effects 才有那么点动静，然而还是非常初级的阶段（甚至可以说几乎就是换了个姿势炒 delimited control 的冷饭）。这样的进展恐怕最终并不会比第一次 AI winter 后差不多就熄火了的 LP 方面的研究高明到哪去。
举这个例子的另一个原因是，上述关于 computational effect 的研究很可能就是要做好 query language 但搞 DB 传统上就会忽视的和通用 PL 的“最大公约数”特性集的一个必要基础理论进展（主要原因是 query 本身虽然表面上 pure ，但是要做“好”query 很大程度上是 side-effectful 的，像用户自定义 effect 的局部优化策略的可表达性以及和被嵌入的环境的一致性问题上都有很大的改进空间）。
所以要靠传统意义的上 PL 研究来帮助 query language 系统性地做基础和顶层设计，短期应该是没多少指望的。于是这部分很可能仍然得搞 DB 的用户自己闭门造车。当然只是要 do better ，正常发挥下，也确实有不小可行性——至少对付 SQL 不难，因为 SQL 很多方面真的明显太辣鸡了；但是，最好别指望有多大的革命性突破，更不要指望能改变现有 DB 用户的使用习惯甚至方法论。

[FrankHB]

@fds 当年我也以为微软突然开窍了终于不再抄 UNIX （ NT ） + 套皮 DOS （ Win32 ）了，结果意料之中（？）地半途而废了……

现在商业界应该没啥好对改变这种层次的基本生态有指望了，硬说的话，唯一值得一提的就是苹果——苹果尝试首先在 iOS 上对用户隐藏传统文件系统和文件的抽象，一定程度上至少能缓解“文件”这个抽象混乱的局面（比如用户根本上不用想着纠结跨平台之间的语义差别，像为什么有的系统有所谓“设备文件”之类的玩意儿了）。问题是苹果也没提供啥实质上有效的替代，结果基本就是 API 没 abstraction ，GUI 没 metaphor ，CLI ……整个没有的局面……
题外话，苹果在软硬件结合的方面尝试对 CPU 厂商说“不”而变相架空 ISA 也大体能算是历史视角上可能整体正确的大棋，问题是它的封闭本性使之又不带其他吃 ISA 兼容性坑的小伙伴一起玩……

[fantix]

@FrankHB 感谢码字！我不敢相信我在做中文的阅读理解题归纳总结中心思想……才疏学浅，望指正！你是不是说，通过类比 I/O 在工业 PL 中的错位实现无法反应底层计算作用这一现象，尝试说明传统 PL 的方式方法无法对 DB 领域的查询语言做出革命性的突破，虽然可以超越门槛很低的 SQL ，但真正有意义的方法论级别的创新，还需懂 DB 的人从如何传递和撬动计算作用的角度加以深挖。

[FrankHB]

@fantix 基本是这样没错。不过我对现在 DB 的具体问题不了解，只能提出我认为自顶向下方面的通用 PL 能推动 query language 上最有可能的一个进展。实际上，还有 DB 业界因为解决现有普遍应用的更直接的痛点（比如嵌入其它语言实现的业务代码时开发体验和成品的效果都很不让人满意）而能改变用户习惯也现有业态的可能性，不过这个可能更困难就是了。

[FrankHB]

@fantix 这个其实只是我的一些设想：现有的习惯（包括使用的技术的路径依赖以及行业人员的分工等等）在历史偶然的作用下已经积重难返，或许要有历史上第一次 AI 热潮这样的态度在 PL 领域上来一次文艺复兴，把现在知道的一些周知问题（特别是兼容包袱）甩掉另起炉灶，然后逐步替代现有的设计和实现，来解决一些关键的历史遗留问题；接下来自然地推广到应用，而效益上最显著的应用就是 DB 领域的 DSL 。
当然这显然过于理想化了。现实条件不成熟（有多少人对改变历史遗留问题感兴趣就是问题，然后工作量还大得离谱），实在不现实。

[fantix]

@FrankHB 虽然 PL 的话题超过我的认知太多了，但我还是要说，有理想总是好的。我先尝试跟老板在这个角度聊一下吧，看他们野心有多大。看了你的 GitHub 和 mailing list ，你在参与维护 C++？

[FrankHB]

@fantix 现在躺了，偶尔酱油。

[charlie21]

@FrankHB #26 我是指 app developer 对程序的诊断方式，也是 SDK developer 允许 app developer 有的诊断方式，是只能在已经给出的 interface 上诊断问题，头痛医头 脚痛医脚，短平快的补丁。很少人会去拆看 interface 之下的东西 即使也不敢动 因为不知道哪里会 ‘牵一发而动全身’（只能报告给 SDK developer 去做，而且人家可能还觉得这不是一个问题 而是一个 feature ，有助于保持 interface 的一致性）。不会不能不必去深究，那么补丁会越来越多，人们对于继有的 platform 的依赖也越来越大。当然 lz 这个属于再造一个新的 inteface / platform 了

[Braisdom]

@fantix 很早以前吐槽过。

https://www.v2ex.com/t/727939#reply163

[fantix]

@Braisdom 👍👍值得尊敬的项目

[zoharSoul]

还是有点意思的