较小的日志

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

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

存储过程的更多优点:

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

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

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

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

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

存储过程的优点 1).提高安全性，因为存储过程中的SQL本质上是静态的(大多数)。这将防止SQL注入。 2)。可重用性。如果需要为多个应用程序/组件返回相同的数据，这可能是一个更好的选择，而不是重复SQL语句。 3).减少客户端与数据库服务器之间的调用。

我不确定其他数据库，但您可以在大型机上的db2中使用主机语言创建存储过程，这使得它们非常强大。

@Terrapin - scprocs同样容易受到注射攻击。正如我所说:

总是参数化所有的查询-永远不要内联用户输入的东西，你会没事的。

这适用于sprocs和动态Sql。

我不确定不重新编译你的应用程序是一个优势。我的意思是，在重新上线之前，您已经针对该代码(应用程序和DB)运行了单元测试。

@Guy -是的，你是对的，sproc确实让你控制应用程序用户，这样他们就只能执行sproc，而不是底层的操作。

我的问题是:如果所有人都通过你的应用程序访问它，使用连接和用户只有有限的更新/插入权限等，这个额外的级别是否增加了安全性或额外的管理?

我的观点是后者。如果他们已经破坏了您的应用程序，可以重新编写它，那么他们还有很多其他的攻击可以使用。

如果动态内联代码，Sql注入仍然可以针对这些spprocs执行，所以黄金法则仍然适用，所有用户输入必须始终参数化。