使用大量复杂的存储过程有什么好处

Question

对于典型的3层应用程序,我看到在许多情况下,它们在数据库中使用了大量复杂的存储过程.我无法从这种方法中获益.根据我个人的理解,这种方法存在以下缺点:

1. 交易变得粗糙.
2. 业务逻辑进入数据库.
3. 大量计算是在数据库服务器中完成的,而不是在应用程序服务器中完成的.同时,数据库仍然需要完成其原始工作:维护数据.数据库服务器可能成为瓶颈.

我猜可能有两个好处:

1. 无需编译即可更改业务逻辑.但是SP比Java/C#代码更难维护和测试.
2. 减少数据库连接的数量.但是,在常见的情况下,数据库的瓶颈是硬盘而不是网络io.

有谁能告诉我使用大量存储过程的好处,而不是让工作在业务逻辑层完成？

Answer 1

基本上,好处是问题列表的第2个好处 - 如果在数据库后端进行大量处理,那么它在那里处理并且不依赖于访问数据库的应用程序.

当然 - 如果您的应用程序在其业务逻辑层中执行了所有正确的操作,那么事情就可以了.但是,只要第二个和第三个应用程序需要连接到您的数据库,突然他们也必须确保遵守所有业务规则等 - 或者他们可能不会.

将业务规则和业务逻辑放在数据库中可确保无论应用程序,脚本,Excel管理员如何访问您的数据库,都将强制执行业务规则并保护您的数据完整性.

这是存储过程而不是基于代码的BLL的主要原因.

此外,使用Views for read和Stored Procs进行更新/插入,DBA可以删除对基础表的任何直接权限.您的用户不再需要拥有表中的所有权限,因此,您的表中的数据可以更好地防止意外或恶意更改.

使用存储过程方法还使您能够通过存储过程监视和审计数据库访问 - 没有人能够声称他们没有更改该数据 - 您可以轻松地证明它.

总而言之:对您的数据越关键,您希望围绕它构建的保护层越多.这就是使用存储过程的原因 - 并且它们也不需要复杂 - 并且大多数存储过程可以使用代码生成基于表结构生成,因此它也不是一个很大的打字工作.