我继承了一个严格使用存储过程来完成工作的Web应用程序。我喜欢让前端开发人员无法破坏数据库的方法，但我已经厌倦了用纯SQL编写SP调用并希望有更好的东西。虽然我一直在寻找一个体面的ORM（在这种情况下用于Perl，但这与问题无关）并支持存储过程，但我意识到ORM可能与SP直接矛盾。
我的想法是SP就像名字已经告诉我们的那样，程序，即程序Pascal式编程的代表，实际上，一个Web应用程序看起来与SQL-Server端的Pascal完全一样 - 很多功能，没有真正的名字空间。与此相反，我们试图完成大部分编程OOP风格（或功能，这是另一个主题），因此实际上，过程SP并不适合干净的对象层次结构。同时，关系逻辑可以干净地（通过ORM）转换为对象，但不是程序，这可能是大多数ORM不能很好地支持SP的原因（但我不是该领域的专家）。在某种意义上，SP 是 ORM。
所以这两个问题是：
答案 0 :(得分：8)
“我是否正确地假设我们在运行ORM时最好使用普通表？”
是
RDBMS应该专注于持久存储，仅此而已。
如果你这样做，你会发现你可以 - 轻松 - 用你的OO语言建立一个访问层。所有“前端”开发人员都必须使用访问层，不能破坏数据库。
“面向对象的存储过程？”
Oracle有一些类似于OO的PL / SQL功能。
不要浪费任何时间。专注于持久性（在RDBMS中）和应用程序处理（不在RDBMS中）之间的清晰分离。
许多人会向你发送讨厌的邮件，说“供应商把所有这些功能放在那里，这意味着你应该使用它们”和“存储过程有什么问题？”并且“一个优秀的DBA比一个充满前端开发人员的房间”等等。
我不知道为什么人们声称存储过程“更好”，但许多系统最终到达了存储过程和触发器变得如此繁重以至于必须重写的墙。
我从未见过有人抱怨他们在数据库外面有太多的应用程序软件。
继续关注您的想法 - 使用ORM - 避免存储过程。
答案 1 :(得分：3)
这个问题没有明确的黑白回答。双方都存在许多相互矛盾的论点，而我（imho）尚未看到明确的共识出现。对于相反的观点，有理性的论证，请参阅 ORM - Vietnam of CS，或 another ORM link。
答案 2 :(得分：2)
大多数ORM工具（我已经使用过。我在.NET世界中）提供了一种使用存储过程的机制。因为ORM工具（再次，我使用的那些）默认选择所有列，所以它们都被加载到对象图中，所以通常必须编写SPROC以选择所有列。对象图的一部分。这是我在使用ORM包时遇到的唯一一个奇怪的问题。
通常有一些方法可以在ORM工具中优化您的SPROC调用，因此他们不需要选择所有列，但这通常更高级。
我认为这样做是安全的，但一般来说，当你需要通过正常的ORM方法优化速度很慢时，你只需要/需要这样做。
答案 3 :(得分：1)
在.NET中，LINQ数据类将为过程生成强类型类。您可以调用以下过程：
foreach (var customer in db.GetCustomers())
Console.WriteLine(customer.firstName);
其中GetCustomers（）是数据库中的存储过程。但是您无法更新返回的客户并将更改提交到数据库。 ORM只能使用普通表来执行此操作。
我的体验与S.Lot相反，存储过程层使我的数据库保持一致，干净和快速。我想这取决于应用程序的大小和复杂程度，以及您对SQL的了解程度。