sql - 将 ORM 与存储过程一起使用，矛盾吗？

Question

我继承了一个严格使用存储过程来完成其工作的 Web 应用程序。我喜欢让前端开发人员不可能破坏数据库的方法，但我已经厌倦了用普通的 SQL 编写对 SP 的调用，并希望有一些更理智的东西。虽然我一直在寻找一个体面的 ORM(在这种情况下是 Perl，但这与问题无关)并支持存储过程，但我已经意识到 ORM 可能与 SP 直接矛盾。

我的想法是，正如名字已经告诉我们的那样，SP 是过程，即过程式 Pascal 编程风格的代表，事实上，一个 Web 应用程序在 SQL-Server 端看起来与 Pascal 完全一样——许多功能，没有真正的命名空间。与此相反，我们正在尝试以 OOP 风格(或函数式，这是另一个主题)进行大部分编程，因此实际上过程式 SP 不太适合干净的对象层次结构。同时，关系逻辑可以干净地转换为对象(通过 ORM)，但不能转换为过程，这可能是大多数 ORM 不能很好地支持 SP 的原因(但我不是该领域的专家)。从某种意义上说，SP 是 ORM。

所以两个问题是:

我是否认为在运行 ORM 时最好使用普通表？

市场上是否有从关系模型构建的“面向对象的存储过程”？显然，有面向对象的数据库，但我对“服务器端的 ORM”感兴趣。

Answer 1

“我认为我们在运行 ORM 时最好使用普通表是对的吗？”

是的。

RDBMS 应该专注于持久存储，仅此而已。

如果您这样做，您会发现您可以——轻松地——用您的 OO 语言构建一个访问层。所有“前端”开发者都必须使用访问层，不能破坏数据库。

“面向对象的存储过程？”

Oracle 有一些类似于 OO 的 PL/SQL 特性。

不要在上面浪费任何时间。专注于持久性(在 RDBMS 中)和应用程序处理(不在 RDBMS 中)之间的清晰分离。

很多很多人会向您发送讨厌的邮件，说“供应商将所有这些功能都放在那里，这意味着您应该使用它们”和“存储过程有什么问题？”以及“一个好的 DBA 胜过一屋子的前端开发人员”等等。

我不知道为什么人们声称存储过程“更好”，但许多系统最终到达了存储过程和触发器变得如此繁重以至于不得不重写的那堵墙。

我从未见过有人提示他们在数据库之外拥有太多应用程序软件。

在这里继续遵循您的想法——使用 ORM——避免存储过程。