程序员希望代码在他们的应用程序中，DBA希望它在数据库中。

如果你两者都有，你可以通过使用存储过程在两者之间分配工作，程序员不必担心所有这些表如何连接在一起等(对不起，我知道你想控制一切。)

我们有一个第三方应用程序，它允许在数据库中的视图或存储过程上创建自定义报告。如果我把代码中的所有逻辑都放在另一个应用程序中，就不能重用它。如果你使用数据库编写所有的应用程序，这不是问题。

使用你的应用程序代码，因为它最擅长:处理逻辑。 使用数据库来做它最擅长的事情:存储数据。

您可以调试存储过程，但是您会发现在代码中调试和维护逻辑更容易。 通常，每次更改数据库模型时，都需要重新编译代码。

此外，具有可选搜索参数的存储过程是非常不有效的，因为您必须预先指定所有可能的参数，而复杂的搜索有时是不可能的，因为您无法预测一个参数将在搜索中重复出现多少次。

SQL注入攻击呈上升趋势。有人很容易找到这些代码并在你的网站上运行注入攻击。您必须始终始终将查询参数化。最好不要在动态SQL查询上运行exec(@x)。在我看来，使用内联SQL并不是一个好主意。

有些人认为，存储过程很麻烦，因为它们是另一组需要与代码分开维护的项。但是它们是可重用的，如果你在查询中发现了一个错误，你可以在不重新编译的情况下修复它们。

存储过程的优先级，因为: 在系统运行时修复一些生产中与数据相关的问题(这对我来说是第一个) - DB和程序之间清晰的契约定义(清晰的关注点分离) -更好的可移植性到不同的DB供应商(如果写得好，代码更改通常只在SP端)。 -更好地进行性能调优

缺点:WHERE子句在使用条件上有很大的变化，需要高性能。

SQL存储过程不会提高查询的性能

我喜欢存储过程，不知道有多少次我能够使用存储过程对应用程序进行更改，而不会对应用程序产生任何停机时间。

作为Transact SQL的忠实粉丝，调优大型查询已被证明对我非常有用。我已经6年没有写过任何内联SQL了!