存储过程--末日

Question

我正在收听Hanselminutes播客："StackOverflow使用ASP.NET MVC - Jeff Atwood和他的技术团队“。在播客的过程中，他们谈到了SQL server，并说了一些关于“存储过程的日子已经结束了”的话。

现在我不是DBA了，但这让我有点惊讶。我一直认为SP是追求速度(因为它们都符合)和安全性的方法，更不用说可伸缩性和可维护性了。如果不是这样的话，SP已经走到了最后一步，我们将用什么来取代他们，或者我们将来应该做什么？

Answer 1

也许我太守旧了，或者太懒了，或者两者兼而有之，但我不能同意。存储过程一次又一次地“拯救了今天”，因为当一个小的后端变化或错误出现时，我们只需要修复存储过程，而不是在几十个桌面和web服务器上更新桌面应用程序。此外，用户不会被打断。这节省了大量的精力和用户的麻烦。

此外，一些数据库操作在服务器上会更有效率，而不是在网络上来回运行，例如。当一个存储过程调用另一个存储过程时，该存储过程调用另一个存储过程，等等(使用或不使用游标)

编辑:在SOA架构中，客户端应用程序的更新问题得到了缓解(感谢maud-dib)，但存储过程之间的相互调用仍然比SOA层的多次网络往返更有效。而且，更新SOA层也不总是那么简单。

Answer 2

在现代系统上，参数化查询是在服务器上编译和缓存的，因此它们与存储过程一样快。它们也具有大多数相同的安全功能。

对于服务于单个应用程序的数据库，将查询逻辑放在代码中的相关位置更有意义。如果没有其他事情，它会让源代码控制变得更容易。如果将存储过程保存在服务器上，跟踪它们很快就会变得一团糟。此外，如果您正在使用ORM工具，那么您可能对真正的SQL没有太多的了解。

如果您数据库服务于多个不同的应用程序，那么您可能仍然希望使用存储过程在应用程序之间强制执行业务规则。

Answer 3

我要说的是，SP是不可维护的，而且它们也不能扩展。询问任何必须向SP密集型系统添加功能的开发人员。为什么你有一半的逻辑在不同的层？没有什么可以替换的，就是别用它们。

Googled this great post.