我对存储过程的投票;作为接近数据的抽象层，集合高效，可被许多“客户端”(客户端语言)重用。T-SQL语言有点原始(我猜这是SO的大多数c#人都接触过的)，但Oracle的PL/SQL与任何现代编程语言不相上下。

至于版本控制，只需将存储过程代码放在版本控制下的文本文件中，然后运行脚本在数据库中创建procs。

很明显，使用存储过程比在代码中构造SQL有几个优点。

代码实现和SQL变得彼此独立。 代码更容易阅读。 写一次用多次。 修改一次 不需要向程序员提供关于数据库的内部细节。等等，等等。

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

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

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

这里是另一个当前的讨论

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

此外，正如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差)。

Definitely easier to maintain if you put it in a stored procedure. If there's difficult logic involved that will potentially change in the future it is definitely a good idea to put it in the database when you have multiple clients connecting. For example I'm working on an application right now that has an end user web interface and an administrative desktop application, both of which share a database (obviously) and I'm trying to keep as much logic on the database as possible. This is a perfect example of the DRY principle.

存储过程的优点:

更容易检查代码。

耦合更少，因此更容易测试。

更容易调谐。

从网络流量的角度来看，性能通常更好——如果您有一个游标或类似的东西，那么就不会多次访问数据库

您可以更容易地保护对数据的访问，删除对表的直接访问，通过procs加强安全性——这也允许您相对快速地找到更新表的任何代码。

如果涉及到其他服务(如Reporting服务)，您可能会发现将所有逻辑存储在存储过程中，而不是存储在代码中，并且必须复制它会更容易

缺点:

对开发人员来说更难管理的是:脚本的版本控制:每个人都有自己的数据库吗?版本控制系统是否与数据库和IDE集成在一起?