我更喜欢把它们保存在代码中(使用ORM，而不是内联或特别)，这样它们就可以被源代码控制覆盖，而不必保存.sql文件。

此外，存储过程本身并不更安全。使用sproc可以像使用内联一样轻松地编写糟糕的查询。参数化内联查询与sproc一样安全。

Something that I haven't seen mentioned thus far: the people who know the database best aren't always the people that write the application code. Stored procedures give the database folks a way to interface with programmers that don't really want to learn that much about SQL. Large--and especially legacy--databases aren't the easiest things to completely understand, so programmers might just prefer a simple interface that gives them what they need: let the DBAs figure out how to join the 17 tables to make that happen.

话虽如此，用于编写存储过程的语言(PL/SQL就是一个臭名昭著的例子)是相当残酷的。它们通常不提供您在当今流行的命令式语言、OOP或函数式语言中看到的任何细节。认为COBOL。

因此，请坚持使用仅抽象了关系细节的存储过程，而不是那些包含业务逻辑的存储过程。

我不是存储过程的狂热爱好者，但我在一种情况下使用它们:

当查询相当大时，最好将其作为存储过程存储在数据库中，而不是从代码中发送。这样，就不会从应用服务器向数据库发送大量字符串字符，而只发送“EXEC SPNAME”命令。

当数据库服务器和web服务器不在同一个网络上(例如，internet通信)时，这是多余的。即使事实并非如此，太大的压力也意味着大量的带宽浪费。

但是，伙计，管理起来太糟糕了。我尽量避开他们。

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

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

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

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

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

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

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

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.

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

存储过程的更多优点:

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