对我来说这是非常常见但很重要的问题，因为在我的项目中，我开始将硬编码查询转换为存储过程，我知道使用它的优势。但是，我是否应该避免使用存储过程？
答案 0 :(得分：6)
我发送给每个人的标准博客文章，他们认为存储过程总是有意义的，除非在非常罕见的情况下。他们通常会引用一个谬论，你只需要制定法律来制止杀人，以阻止凶手。
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
上面的链接列出了很多关于何时以及何时不使用存储过程的非常好的论据。其中包括，特别是在C＃中，你基本上忽略了框架为你提供的所有内容，以及为查询做出合理的UI决策的能力，支持......维护噩梦。
答案 1 :(得分：4)
使用存储过程通常总是更好。使用它们时，主要优点是如果多次运行查询，使用存储过程将保留执行计划以供重用。
使用它们有很多好处，请参阅此处以供参考：http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/
编辑：虽然文章来自2007年，但主要原则基本相同
答案 2 :(得分：3)
这个问题被问了很多，here是关于这个主题的好帖子。
但是我个人会说避免存储过程中的复杂逻辑很难在以后维护，并且不是最好的地方。 ORM映射器现在使用得非常广泛，一些较大的映射器（Hibernate / NHIbernate，EF等）都可以生成视频查询并具有出色的缓存策略。
还要避免一个有很多存储过程的系统（我已经看过一个存储过程超过4k的系统并相信我你不想去那里）。
修改
我应该扩展我的答案并且现在会这样做，但存储过程确实很有用，因为它们在服务器本身上执行它们很好，需要处理大量数据而不是通过网络连接，您可能需要多次往返数据库以获得相同的结果，然后我倾向于在存储过程中进行优化，大多数ORMS可以执行sproc并带回映射结果，因此这增加了orm解决方案的丰富性。
但是如果你发现你正在做的只是通过ORM执行sprocs，那么你真的不需要orm。所以这些天它的性能优化。涉及大型数据集的地方。还有很多来自开发者和DBA的错误观点/习惯，这可能导致类似战争的事态，人们被告知“所有代码必须在sprocs中”或“所有代码都必须生成通过orm“，这是一种愚蠢的事态。
我要指出的另一件事是我已经看到了其中存在各种错误的sprocs，而且我们的本质软件开发人员通常不是编写sql的最佳人选，因为我们不倾向于在“集合的“方式。多数民众赞成不是说开发人员不能写出优秀的sql代码，而不仅仅是我们的专业。
你有多少次看到一个代码路径下降的sproc ...得到它的计划被缓存然后因此不是最理想的因为每次后来它都没有沿着这条路走......我见过很多。
答案 3 :(得分：1)
最佳做法是使用存储过程。