较小的日志

存储过程的另一个小优点是没有提到的:当涉及到SQL流量时，基于sp的数据访问产生的流量要少得多。当您监视流量进行分析和分析时，这一点变得非常重要——日志将会更小且可读。

当存储过程被用于应用程序和数据库之间时，它们是最糟糕的。上面提到的使用它们的许多原因都可以由视图更好地处理。

有关安全的论点是站不住脚的。它只是将安全问题从应用程序转移到数据库。代码就是代码。我曾见过一些存储过程从应用程序中获取SQL，并使用它构建容易受到SQL注入攻击的查询。

一般来说，它们往往会在所谓的数据库开发人员和所谓的应用程序开发人员之间造成裂痕。实际上，所有编写的代码都是应用程序代码，只是执行上下文的不同。

使用丰富的SQL生成库，如LINQ, Rails ActiveRecord或Hibernate/NHibernate，使开发更快。在混合中插入存储过程会降低速度。

我参加的Microsoft TechEd安全会议的建议之一是，通过存储过程进行所有调用，并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做，但如果您已经在使用存储过程，那么这样做也无妨。

较小的日志

存储过程的另一个小优点是没有提到的:当涉及到SQL流量时，基于sp的数据访问产生的流量要少得多。当您监视流量进行分析和分析时，这一点变得非常重要——日志将会更小且可读。

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

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

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

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