与硬编码查询相比，使用存储过程的优势在哪里

我有一篇标准的博客文章发给所有认为存储过程总是有意义的人，除非在非常罕见的情况下。他们通常引用一种谬论，认为你只需要制定一项禁止杀人的法律就可以阻止杀人犯。

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

上面的链接列出了很多关于何时以及何时不使用存储过程的非常好的论点。其中包括，尤其是在C#中，你基本上忽略了框架给你的一切，就为查询做出明智的UI决策的能力而言，你倾向于。。。维护噩梦。

通常最好使用存储过程。使用它们的主要优点是，如果您多次运行查询，那么使用存储过程，它将保留执行计划以供重用。

使用它们有很多优点，请参阅此处以供参考：http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/

编辑：虽然这篇文章来自2007年，但关键原则基本相同

这个问题被问了很多，这里有一篇关于这个主题的好文章。

然而，我个人想说的是，避免存储过程中的复杂逻辑，这在以后很难维护，也不是放置它的最佳位置。ORM映射器现在被广泛使用，一些更大的映射器（Hibernate/NHIbernate、EF等）都会生成视景查询，并具有出色的缓存策略。

还要避免使用存储了很多很多proc的系统（我见过一个存储了超过4k的proc，相信我，你不想去那里）。

编辑

我本应该扩展我的答案，现在也会这样做。然而，存储过程确实有很大的用处，因为它们是在服务器上执行的。在需要处理大量数据而不是通过网络连接回购的情况下，存储过程非常好，你可能需要多次往返数据库才能获得相同的结果，然后我倾向于在存储过程中进行观察，大多数ORMS可以执行存储过程并返回映射的结果，因此这增加了orm解决方案的丰富性。

但是，如果您发现您所做的只是通过ORM专门执行sproc，那么您实际上并不需要ORM。所以现在这是一种性能验光。涉及大型数据集时。此外，开发人员和DBA往往都有很多错误的意见/习惯，这可能会导致类似战争的状态，人们被告知"所有代码都必须在sproc中"或"所有代码必须由orm生成"，这是一种愚蠢的状态。

我要指出的另一件事是，我见过有各种错误的sproc，从本质上讲，软件开发人员通常不是编写sql的最佳人选，因为我们不倾向于以"集合式"的方式思考。这并不是说开发人员不能编写出色的sql代码——这不是我们的专长。

一个存储过程在代码路径上运行一次，您见过多少次。。缓存了它的计划，结果是次优的，因为以后每次它都不会沿着这条路走。。。我已经看到很多了。

最佳做法是使用存储过程。

1. 工作分离
2. 可重用（可以直接从SQL进行测试）
3. 您可以将一个过程用于多种目的，如果您的软件发生某些更改，它将减少您的时间
4. 不需要替换程序中的任何代码，特别是在DLL中