我仍然更喜欢DBA端的存储过程,原因如下(其中一些可能会对性能产生巨大影响)：

>如果我有多个应用程序重复使用相同的查询,则存储过程会封装该逻辑,而不是在不同的代码库中多次乱丢相同的即席查询.重复使用相同查询的应用程序也可能受到计划缓存膨胀的影响,除非它们是逐字复制的.即使案例和空白区域的差异也可能导致同一计划的多个版本被存储(浪费).
>我可以检查和解决查询正在执行的操作,而无需访问应用程序源代码或运行昂贵的跟踪以查看应用程序正在执行的操作.
>我还可以控制(并事先知道)应用程序可以运行什么查询,它可以访问哪些表以及在什么上下文中等.如果开发人员在他们的应用程序中临时编写查询,他们要么会有每当他们需要进入我不知道或无法预测的桌子时,或者如果我不那么负责任/热情和/或有安全意识的话,那就来拉我的衬衫袖子,我只是要推广那个用户dbo让他们不再烦我.通常,当开发人员数量超过DBA或DBA很顽固时,就会完成此操作.最后一点是我们的不好,我们需要更好地提供您需要的查询.
>在相关的说明中,一组存储过程是一种非常简单的方法,可以准确地清点可能在我的系统上运行的查询.一旦允许应用程序绕过过程并提交自己的即席查询,为了找到它们,我必须运行一个涵盖整个业务周期的跟踪,或者解析所有应用程序代码(同样,我可能无权访问)找到任何看起来像查询的东西.能够查看存储过程列表(以及grep单个源,sys.sql_modules,用于对特定对象的引用)使每个人的生活变得更加容易.
>我可以花更多的时间来防止sql注入;即使我接受输入并使用动态sql执行它,我也可以控制许多允许发生的事情.在构造内联sql语句时,我无法控制开发人员正在做什么.
>我可以优化查询(或查询),而无需访问应用程序源代码,进行更改的能力,应用程序语言的知识有效地执行,权限(更不用说麻烦)重新编译和重新部署应用程序等.如果应用程序是分发的,这尤其成问题.
>我可以强制存储过程中的某些设置选项,以避免单个查询受到某些Slow in the application,fast in SSMS?问题的影响.这意味着,对于调用即席查询的两个不同应用程序,可以将SET ANSI_WARNINGS设置为ON,另一个可以设置SET ANSI_WARNINGS,并且每个应用程序都有自己的计划副本.他们获得的计划取决于使用的参数,现有的统计数据等.在每种情况下第一次调用查询时,这可能导致不同的计划,从而导致非常不同的性能.
>我可以控制数据类型和参数的使用方式,与某些ORM不同 – 某些早期版本的EF会根据参数的长度参数化查询,所以如果我有一个参数N’Smith’和另一个N ‘约翰逊’我会得到两个不同版本的计划.他们已经解决了这个问题.他们已经解决了这个问题,但还有什么问题仍然存在？
>我可以做ORM和其他“有用的”框架和库尚不能支持的事情.

这一切都说,这个问题可能会引发更多的宗教争论,而不是技术辩论.如果我们看到这种情况发生,我们可能会将其关闭.