在安全性方面，存储过程要安全得多。一些人认为，无论如何，所有的访问都将通过应用程序进行。许多人忘记了一件事，即大多数安全漏洞来自公司内部。想想有多少开发人员知道应用程序的“隐藏”用户名和密码?

此外，正如MatthieuF所指出的，由于应用程序(无论是在桌面服务器还是web服务器上)和数据库服务器之间的往返次数减少，性能可以得到很大的提高。

In my experience the abstraction of the data model through stored procedures also vastly improves maintainability. As someone who has had to maintain many databases in the past, it's such a relief when confronted with a required model change to be able to simply change a stored procedure or two and have the change be completely transparent to ALL outside applications. Many times your application isn't the only one pointed at a database - there are other applications, reporting solutions, etc. so tracking down all of those affected points can be a hassle with open access to the tables.

我还将在加分栏中加上检查，以使SQL编程掌握在专门的人员手中，并使sp更容易隔离和测试/优化代码。

我看到的一个缺点是，许多语言不允许传递表参数，因此传递未知的数据值可能很烦人，一些语言仍然无法处理从单个存储过程中检索多个结果集(尽管后者在这方面并不使sp比内联SQL差)。

存储过程更易于维护，因为:

你不需要重新编译你的c#应用每当你想改变一些SQL 您最终会重用SQL代码。

当您试图构建可维护的应用程序时，代码重复是最糟糕的事情!

当您发现需要在多个地方纠正的逻辑错误时会发生什么?您更容易忘记更改复制和粘贴代码的最后一个位置。

在我看来，性能和安全性的提高是一个额外的加分项。您仍然可以编写不安全/低效的SQL存储过程。

更容易移植到另一个DB -没有pros到移植

在另一个DB中创建所有存储过程并不难。事实上，它比导出表更容易，因为不需要担心主键/外键。

目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者，尽管有一些很好的论据支持Linq to Sql。

在代码中嵌入查询将您与数据模型紧密地结合在一起。存储过程是一种很好的契约式编程形式，这意味着DBA可以自由地更改过程中的数据模型和代码，只要存储过程的输入和输出所表示的契约得到维护。

当查询隐藏在代码中，而不是在一个易于管理的中心位置时，调优生产数据库可能会非常困难。

这里是另一个当前的讨论

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

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

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

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

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

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

我们在Oracle数据库中使用存储过程。我们也使用Subversion。所有存储过程都被创建为.pkb & .pks文件并保存在Subversion中。我以前做过内嵌SQL，这很痛苦!我更喜欢我们在这里的方式。创建和测试新的存储过程比在代码中执行要容易得多。

特蕾莎

我站在代码这一边。我们构建了所有应用程序(包括web和客户端)使用的数据访问层，所以从这个角度来看这是DRY。它简化了数据库部署，因为我们只需要确保表模式是正确的。它简化了代码维护，因为我们不需要查看源代码和数据库。

在与数据模型的紧密耦合方面，我没有遇到太多问题，因为我看不出哪里有可能真正打破这种耦合。应用程序及其数据在本质上是耦合的。