我想再投一票赞成使用存储过程(尽管在维护和版本控制时它们会带来麻烦)作为一种限制对底层表的直接访问以获得更好的安全性的方法。

存储过程的性能优势通常可以忽略不计。

存储过程的更多优点:

防止反向工程(当然，如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便

存储过程。

如果出现错误或者逻辑稍有变化，您不必重新编译项目。此外，它允许从不同的来源访问，而不仅仅是在项目中编写查询的一个地方。

我不认为维护存储过程更难，你不应该直接在数据库中编写它们，而应该先在单独的文件中编写，然后你可以在任何你需要设置的DB上运行它们。

我参加的Microsoft TechEd安全会议的建议之一是，通过存储过程进行所有调用，并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做，但如果您已经在使用存储过程，那么这样做也无妨。

存储过程比代码更容易在数据库和源代码控制系统之间失去同步。应用程序代码也可以，但当您进行持续集成时，这种可能性较小。

数据库就是这样，人们不可避免地对生产数据库进行更改，只是为了暂时摆脱困境。然后忘记在环境和源代码控制系统之间同步它。生产数据库迟早会成为事实上的记录，而不是源代码控制系统——您将陷入无法删除任何scprocs的情况，因为您不知道它是否正在被使用。

一个好的过程应该只允许通过适当的渠道对产品进行更改，这样您就能够从源代码控制系统(无数据)从头开始重新构建数据库。但我只是说，因为它可以完成，也确实完成了——在最激烈的时刻，在大喊大叫的客户的电话之间，在紧盯着你的经理的电话之间，等等，对生产数据库进行了更改。

使用存储过程运行特别查询很尴尬——使用动态sql(或ORM)更容易，这可能是我自己使用存储过程的最大缺点。

另一方面，存储过程在你做出更改但不需要重新部署应用程序代码的情况下很好。它还允许您在通过网络发送数据之前对数据进行塑形，而代码中的sql可能必须进行多次调用来检索而不是塑形(尽管现在有方法可以在一次“调用”中运行多个sql语句并返回多个结果集，如ADO.NET中的MARS)，这可能会导致更多的数据通过网络传输。

不过，我不相信任何关于性能和安全性的争论。两者都有可能是好的，也有可能是坏的，而且同样可控。

程序员希望代码在他们的应用程序中，DBA希望它在数据库中。

如果你两者都有，你可以通过使用存储过程在两者之间分配工作，程序员不必担心所有这些表如何连接在一起等(对不起，我知道你想控制一切。)

我们有一个第三方应用程序，它允许在数据库中的视图或存储过程上创建自定义报告。如果我把代码中的所有逻辑都放在另一个应用程序中，就不能重用它。如果你使用数据库编写所有的应用程序，这不是问题。