展开讨论

经验与复盘经验摘录 · 机器翻译

- 拒绝了90年代一家软件巨头的邀请,去为其添加数据库功能……

… - 拒绝了一家90年代软件巨头的提议,让他们在其主要语言中添加数据库功能(基本上是将我之前在对象数据库公司开发的功能加入到他们的语言中)。- 设计并构建了一个Java ORM(90年代末期)。在从事这些工作大约20年后,我得出结论,这一切都是错误的。尽管SQL看起来丑陋且奇怪,但它被设计用来满足某些特定的需求,并且取得了巨大的成功。新的数据库编程语言在被接受方面面临巨大的问题,而且需要解决现在SQL已经处理的问题。(30年前更容易,因为那时SQL还处于早期阶段。现在基本上是不可能的。)ORM是一个糟糕的主意,属于“现在你有两个问题”的范畴。你不仅需要编写高性能的查询,还必须确保你的ORM实际发出这些查询。(是的,ORM有转义到原始SQL的功能。这些转义功能的存在恰恰证明了我的观点。)而且模式会变化,你的语言模型的映射也必须变化,这很混乱。直接使用SQL就行了。…

源讨论重新思考数据库编程原帖 161 条评论 · 导入时统计
2

社区评论 0

还没有社区评论,来聊聊你的看法。

原讨论中的回复 2

仅展示本次导入中包含的直接回复。中文为机器翻译,可查看英文原文。

PJ

根据你的经历,你对存储过程有什么看法? 我喜欢它们,认为在数据库中可以完成的事情应该留在数据库中,而许多这些顶层的抽象都是为了避免仅仅实现它们的方式。 而且主要原因,数据库的可移植性,在现实中很少发生,大多数产品仍然使用最初创建它们的数据库。

完整原文
SE

我始终无法理解的是,为什么SQL本身不是攻击的目标。规划器已经存在固有的语言抽象;理论上,Postgres可以成为JVM,上面可以实现任何数量的语言。包括一种适合组合和自动生成PL函数的语言。 ORM从根本上来说很难,是因为映射问题,但SQL代码生成器应该很简单。自动生成并将所有数据库功能作为类型安全的$LANG函数暴露出来应该很简单。相反,它们也因为构建SQL本身很困难而变得意外地困难。 除了SQL之外,你还有Datalog……也就只有这些了。还有就是NoSQL阵营不断制造的那些灾难。

完整原文
在 Hacker News 阅读

尊重不同观点,分享具体经验。

登录后即可发帖、评论、转发和引用。