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

Question

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

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

我猜可能有两个好处：

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

不要害怕数据库。

我们也不要将业务逻辑与数据逻辑混淆，后者在数据库中具有应有的位置。

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

仅供参考，我所使用的最成功和可扩展的“企业/商业”软件实现将所有投影查询放入视图中，并将所有数据管理放入DB过程或分阶段表上的触发器。

Answer 3

appServer和sqlServer之间的网络经常是瓶颈。 需要执行复杂查询时需要存储过程。 例如，您希望通过姓氏收集有关员工的一些数据。特别想象一下，DB中的数据看起来像某种树 - 表A中有关于此员工的3条记录。表B中的每条记录中有10条记录。表C中的每条记录有100条记录。表B.并且您希望从表C中获得关于该员工的特殊5条记录。如果没有存储过程，您将在appServer和sqlServer之间获得大量查询流量，并在appServer中获得大量代码。使用接受员工姓氏的存储过程，获取这5条记录并将它们返回到appServer 1）减少流量数百次，2）大大简化appServer代码。

Answer 4

我们的数据的生命周期超过了我们的应用程序。数据也在应用程序之间共享。如此多的应用程序将数据插入数据库，许多应用程序将从中检索数据。数据库负责数据的完整性，完整性和正确性。因此，它需要有权执行与数据相关的业务规则。

带你具体点：

1. 交易是工作单位。一世 不明白为什么要实施 存储过程中的事务 应该改变它们的粒度。
2. 适用于的商业逻辑 数据属于数据：那 最大化凝聚力。
3. 很难写出好的SQL和     学会成套思考。因此     可能看起来数据库是     瓶颈。事实上，如果我们是     做了很多工作     与数据库的数据有关     可能是最有效的地方     做。

至于维护：如果我们熟悉PL / SQL，T-SQL等，维护比从外部看起来更容易。但我承认，重构之类的工具支持落后于其他语言。

Answer 5

您列出了将业务逻辑放入Db的主要原因之一，通常会提供印象，使其更易于维护。

db中通常复杂的SP逻辑允许实际实现代码的更便宜的实现，如果它是一个过渡应用程序（比如从遗留代码移植而来）可能是有益的，其代码需要以多种语言实现（对于实例在不同平台或设备上推向市场）或因为问题在db中更容易解决。

另一个原因通常是出于安全性或性能原因，通常存在一种通用的“最佳实践”来封装sps中对db的所有访问。根据您的平台以及您正在使用它做的事情，这可能会或可能不会是真实的。

Answer 6

我认为没有。将BL移动到数据库是很糟糕的，但是并非一切都是如此。试着看看Domain Driven Design。这是大量SPROCs的解毒剂。我认为您应该将数据库用作存储业务对象的地方，仅此而已。

然而，SPROC在某些简单的功能上可以更加高效。例如，您可能希望按固定百分比将薪水增加到数据库中的每个员工。通过SPROC可以更快地从数据库中获取所有员工，更新它们然后将其保存回来。

Answer 7

我在一个项目中工作，其中每件事都是在数据库级别完成的。我们写了很多存储过程，并在数据库中做了很多业务验证/逻辑。大多数时候，它成为我们调试的一大开销。

我感受到的优势可能是

• 利用完整的数据库功能。
• 数据库紧张的活动就像很多插入/更新在数据库级别可以做得更好。拨打SP并让它完成所有工作，而不是多次点击数据库。
• 新的数据库服务器可以容纳复杂的操作，因此他们不再将此视为瓶颈。哦是的，我们使用了Oracle。

现在看一下，我认为在应用程序级别可以做得更好，在数据库级别做得更少。

Answer 8

这几乎完全取决于背景。

在服务器上而不是在客户端上工作通常是一个坏主意，因为它会降低服务器的可伸缩性。但是，您必须与预期的工作负载进行平衡（如果您知道在封闭的环境中只有100个用户，您可能不需要可扩展的服务器）和网络流量成本（如果您必须阅读大量数据以应用）计算/进程，然后在服务器上运行这些计算并且只通过网络发送结果可以更便宜/更快。

此外，如果您有自定义客户端应用程序（而不是Web浏览器等），它可以很容易地将更新推送到您的客户端，因为您不需要重新编译和部署客户端代码，只需升级数据库存储过程。

当然，使用存储过程而不是执行动态编译的SQL语句可以更有效（它是预编译的，并且代码不需要上传到服务器）并且有助于封装以使数据库具有更好的完整性/安全性。但是听到它的声音，你谈论的是大量的商业逻辑，而不是简单的效率和安全措施。

与大多数事情一样，需要明智的妥协/平衡。应该使用存储过程来提高效率和安全性，但是您不希望服务器变得不可扩展。

Answer 9

“这种方法存在以下缺点： ... 业务逻辑进入数据库。“

就“业务逻辑”而言，“业务规则”是指“业务规则的执行”，DBMS完全属于“业务逻辑”所属的地方。