使用许多复杂的存储过程有什么好处

Question

对于典型的3层应用程序，我已经看到在许多情况下，它们在数据库中使用了许多复杂的存储过程。我不太能从这种办法中得到好处。据我个人理解，这种做法存在以下缺点：

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

我可以猜到它可能有两个好处：

1. 更改业务逻辑而不进行编译。但是SPs比Java/C#代码更难维护和测试。
2. 减少DB连接的数量。然而，在一般情况下，数据库的瓶颈不是网络io，而是硬盘io。

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

Answer 1

基本上，问题列表的第二个好处是--如果您在数据库后端进行了大量的处理，那么就会在那里处理它，而不依赖于应用程序访问数据库。

当然--如果您的应用程序在其业务逻辑层做了所有正确的事情，那么一切都会好的。但是，当第二个和第三个应用程序需要连接到您的数据库时，它们突然也必须确保遵守所有的业务规则等等--否则它们可能不会。

将业务规则和业务逻辑放在数据库中可以确保无论应用程序、脚本、带有Excel的管理器如何访问数据库，业务规则都将被强制执行，您的数据完整性将得到保护。

这是存储procs而不是基于代码的BLL的主要原因。

此外，使用read和存储Procs的视图进行更新/插入，DBA可以删除对基础表的任何直接权限。您的用户不再需要拥有表上的所有权限，因此，您的表中的数据可以得到更好的保护，不受未察觉或恶意更改的影响。

使用存储的proc方法还可以通过存储的过程监视和审计数据库访问--没有人能够声称他们没有更改数据--您可以很容易地证明它。

因此，总而言之:您的数据越重要，您希望围绕它构建的保护层就越多。这就是使用存储过程的目的--它们也不需要很复杂--而且大多数存储过程都可以基于使用代码生成的表结构生成，所以也不是很大的类型工作。

Answer 2

别害怕数据库。

我们也不要把业务逻辑和数据逻辑混为一谈，因为数据逻辑在DB中有其应有的地位。

好的系统设计人员将通过数据逻辑来包含灵活的业务逻辑，即抽象的业务规则定义，这些定义可以由数据行的(非)存在或属性驱动。

FYI是我工作过的最成功和最可伸缩的“企业/商业”软件实现，它将所有投影查询和所有数据管理都放到了阶段性表上的DB过程或触发器中。

Answer 3

appServer和sqlServer之间的网络常常是瓶颈。当您需要执行复杂的查询时，需要存储过程。例如，您需要收集一些关于雇员姓氏的数据。尤其是想象一下，DB中的数据就像某种树--表A中有3条关于这个雇员的记录。表A中的每条记录在表B中有10条记录，表B中的每条记录都有100条记录，而你只想从表C中得到关于该雇员的特殊5条记录。没有存储过程，您将在appServer和sqlServer之间获得大量查询流量，并在appServer中获得大量代码。使用接受员工姓氏的存储过程，获取这5条记录并将它们返回给appServer you 1)可以减少数百倍的通信量，2)大大简化了appServer代码。