存储过程是世界上最大的IT软件咨询公司之一的糟糕做法？

Question

我在世界三大IT咨询公司之一的一个项目中工作，一位DBA告诉我，公司最佳实践的状态存储过程不是“最佳实践”。这和我学到的一切都是背道而驰的。

存储过程为您提供代码重用和封装(软件开发的两个支柱)、安全性(您可以授予/撤销对存储的单个proc的权限)、保护您免受SQL注入攻击，以及速度方面的帮助(尽管DBA说，从Server 2008开始，即使运行足够多的常规SQL查询也会被编译)。

我们正在使用敏捷软件开发方法开发一个复杂的应用程序。有人能想到为什么他们不想使用存储过程的好理由吗？我的猜测是DBA不想维护那些存储的过程，但是似乎有太多的负面因素来证明这样的设计决策是合理的。

Answer 1

在我从事大型项目的工作经验中，您必须非常清楚业务逻辑在哪里。如果允许单个开发人员将业务逻辑放入业务对象层或存储过程(他们认为合适)，那么大型应用程序就很难理解和维护。

存储过程对于加速某些DB操作是很好的。我的架构决定是将所有逻辑留在应用程序的业务层，并以有针对性的方式使用存储过程，以便在基准测试表明有必要时提高性能。

Answer 2

其基本原理是，依赖存储过程层限制了可移植性，并将您绑定到某个DB。增加的维修费用也是一个原因。我还想就你提出的这一点发表意见：

(存储过程)保护您免受SQL注入攻击。

实际上，参数化查询保护了您，您可以很容易地在纯文本sql查询中这样做。

Answer 3

我同意存储过程的一些原因不是最佳实践。

• 业务和应用程序逻辑应该在代码中，而不是在数据库中。将逻辑放入DB中是在混淆关注点。
• 您不能像常规单元测试项目中的代码一样无缝地测试存储的过程和应用程序逻辑的其余部分。
• 当我编写代码时，我发现存储的过程无助于测试第一次编程。
• 在IDE中调试程序时，存储的过程并不像应用程序代码那样容易调试。
• SP与普通代码的版本控制/源代码控制