没有理由在2024年继续讨厌SQL

如果你不喜欢人体工程学，就使用AI编码助手。没有理由在2024年继续讨厌SQL。
================================================
有很多很好的学术理由将SQL作为默认值（相对于更简单，更干净的查询语言）。同样，有很多理由讨厌英语作为默认语言（相对于更简单，更干净的自然语言）。两者都不是特别务实的对话。

=================================================
每个人都在分享他们的存储过程故事。以下是我的：

15年前，我为一家打包和销售ETF的私人金融机构提供咨询。ETF每天定价，并且每天为所有投资者提供利润/亏损报告。

这份每日报告，按照规定必须及时和准确，完全用PL/SQL编写。包括令人难忘的德国税法计算。数百万行代码。

我去那里是为了数据库的一个主要版本升级。特别是为了解决新版本中出现的所有性能退化。为了提高性能而对逻辑进行的任何更改都是极其敏感的。让我告诉你，开发人员的经验留下了很多需要改进的地方。在语言和工具方面。

所以，存储过程可能很棒。但我建议以这种方式实施德国税法。 

================================================

我写了很多PL/SQL。最疯狂的事情是一个多线程事件处理器，它作为oracle dbms调度程序作业在后台运行。

该系统有一个单独的代理进程，它从一个繁忙的忙碌系统中使用Oracle Streams事件，并通过dbms管道与一组工作进程通信。

事件处理规则/触发器通过将SQL片段添加到规则表来定义。这个装置速度相对较快，并且具有良好的交易处理保证，这对于它所处理的货币事件类型非常重要。 

===============================================
为什么会有人这么做。这绝对是最糟糕的方法，用cobol写同样糟糕
Oracle和PL/SQL几乎同时使用。太可怕了

================================================
在postgresql上使用像PL/Rust这样的东西，我想知道它是否会让逻辑更容易被接受？ 税务代码计算可以写成一个独立的rust库，具有强类型和良好的单元测试。然后PL/Rust函数将成为db和lib之间的垫片。

=============================================
SQL的人机工程学问题不仅仅是一个麻烦。它们严重拖累了整个分析领域。这是一个主要的问题，101级业务问题需要SQL的高级知识。

例如，在一个示例中，计算总数的百分比需要窗口函数或自联接。

当遇到像查询语言这样复杂的工具时，初学者通常会问“我能用这个工具做什么？”，而不是“我应该用这个工具做什么？因为“正确”的问题很难用语言表达，所以根本就不会被问到。

数据分析师通常是技术专家，在感兴趣的领域没有直接经验。在这些情况下，他们不知道他们应该问什么问题。 他们只知道什么问题容易问。

代码助手可以帮助完成一些任务，比如记住函数中参数的顺序，但我认为SQL有更深层次的问题，AI还不能解决。