数据库与代码中的业务逻辑？

Question

作为一名软件工程师，我非常倾向于在应用程序层编写业务逻辑，而通常只依赖于数据库而不仅仅是CRUD（创建检索更新和删除）操作。另一方面，我遇到了在存储过程中编写大量业务逻辑的应用程序（通常是旧的），因此有些人更喜欢在数据库层编写业务逻辑。

对于在存储过程中拥有和/或享受书面/写作业务逻辑的人来说，使用此方法的理由是什么？

Answer 1

我尝试严格限制数据库中的业务逻辑，以便仅需要进行大量查询和更新以执行单个应用程序操作。有些人可能会争辩说，即使这应该在应用程序中，但如果可以的话，我喜欢保持IO。

数据库非常适合CRUD，但如果它们因逻辑而膨胀：

1. 逻辑在哪里变得混乱，
2. 通常，数据库是一个孤岛，并且不会像应用程序服务器那样水平扩展。
3. t_sql / PLsql本质上难以阅读和程序化
4. 您丧失了OOAD的所有好处。

Answer 2

在最大程度上，将您的业务逻辑保持在最可测试和可调试的环境中。将业务逻辑存储在数据库中有一些正当理由存在于其他人的现有答案中，但它们几乎总是远远超过它。

Answer 3

将业务逻辑限制在应用程序层充其量是短视的。经验丰富的专业数据库设计师很少在其系统上使用它。数据库需要有约束和触发器以及存储过程来帮助定义来自任何源的数据将如何进入它。

如果数据库要保持其完整性并确保所有新数据源或数据更改都遵循规则，那么数据库就是放置所需逻辑的地方。将它作为应用程序层是一个等待发生的数据噩梦。数据库不会仅从一个应用程序获取信息。应用程序中的业务逻辑通常被导入无意中绕过（假设您有一个新客户希望将旧的历史数据导入您的系统或大量目标记录，没有人会通过该接口输入一百万个可能的目标，它将在导入中发生。）它也被通过查询窗口所做的更改所绕过以修复一次性问题（例如将所有产品的价格提高10％）。如果您具有应该应用于数据更改的应用程序层逻辑，则不会。现在可以将它放在应用程序层中，没有意义将错误的数据发送到数据库并浪费网络带宽，但是如果不能将它放入数据库中，迟早会导致数据问题。

将所有这些保留在数据库中的另一个原因是，用户可能会犯欺诈行为。如果将所有逻辑放在应用程序层中，则必须授予用户直接访问表的权限。如果将所有逻辑封装在存储过程中，它们可能仅限于执行存储过程允许的内容而不是其他任何内容。我不会考虑允许用户对存储财务记录或个人信息（例如健康记录）的数据库进行任何访问，因为我不允许除了几个dbas之外的任何人以任何形式或形式直接访问生产记录。比许多开发人员意识到的更多欺诈行为，并且几乎没有人认为他们的设计存在可能性。

如果您需要导入大量数据，那么通过数据访问层可能会减慢导入到爬网的速度，因为它不会优先考虑数据库旨在处理的基于集合的操作。

Answer 4

您对“业务逻辑”一词的使用相当模糊。

它可以被解释为包括对数据的约束的强制执行（也称为“业务规则”）。这些明确的执行属于dbms期间。

它也可以被解释为包含诸如“如果新客户到达，然后在一周内我们向他发送欢迎信”之类的内容。试图在数据层中推送这样的东西可能是一个很大的错误。在这种情况下，“创建新的欢迎信”的驱动程序可能应该是也触发新客户行插入的应用程序。想象一下，每个新的数据库行插入都会触发一封新的欢迎信，然后突然我们接管另一家公司，我们必须将该公司的客户整合到我们自己的数据库中......哎哟。

Answer 5

我们在适当的情况下在数据库层中进行大量处理。有很多操作你不想将大数据集拉回到应用程序层来进行分析。对我们来说，这也是一个更容易的部署 - 单点与在所有安装点更新应用程序。但很大程度上取决于您的应用程序及其作用;这里没有一个好的答案。

Answer 6

在几个ocassions中我把'逻辑'放在了sprocs中，因为CRUD可能发生在多个地方。通过“逻辑”，我不得不说它不是真正的业务逻辑，而是更多的“完整性逻辑”。它可能是相同的 - 如果某些内容以某种方式被删除或更新，可能需要进行一些清理，并且如果删除或更新可能来自具有不同代码库的多个工具，则将它放入proc中是有意义的全部使用过。

此外，有时候“业务逻辑线”非常模糊。以报告为例 - 他们可能依赖于存储过程或视图，这些过程或视图封装了关于模式对业务意味着什么的“智能”。您经常根据列值或其他标准看到CASE语句等“做事”吗？可以解释为业务逻辑，但它可能确实属于可以优化的DB等等。

Answer 7

我会说'业务逻辑'是指应用程序流，用户控制，定时操作以及通常“做生意”，那么它应该在应用程序层中。但是，如果这意味着确保无论你如何在数据中挖掘它，它总是有意义并且是一个明智的，非自我冲突的整体，那么执行这些规则的检查就在DB中，绝对没有问题。总是有很多方法可以将数据推送到数据库并在数据库中进行操作。并非所有这些方式都内置了“业务逻辑”。你会发现在凌晨3点通过支持调用的DOS窗口进入数据库的SQL会话是非常自由的，例如它允许的！如果逻辑不在数据库中以确保所有数据更改都有意义，那么您可以肯定，随着时间的推移，数据将变得非常非常紧张。而且由于系统的价值与其所拥有的数据一样有价值，因此投资回报率会大大降低。

Answer 8

将业务逻辑放入数据库的两个充分理由是：

• 它可以保护您的逻辑和数据 针对其他应用程序 可以访问没有的数据库 实现类似的逻辑。
• 数据库设计通常比...更长久 应用层，它减少了 搬到新的时候需要做的工作 客户端的技术。

Answer 9

您经常在数据库层找到业务逻辑，因为进行更改和部署通常会更快。我认为通常最好的意图不是把逻辑放在那里，而是因为它易于部署而最终会在那里出现。

Answer 10

我在一家金融类公司工作，其中某些规则由各州适用，而且这些规则及其计算几乎每天都会发生变化，如果不是每周一次。在这种情况下，将处理计算的逻辑部分移动到数据库更有意义;可以测试和应用更改，而无需重新编译和重新编写应用程序，这在不中断业务的情况下每天都是不可能的。存储过程经过测试，批准，应用，最终用户不是更明智的。 随着向基于Web的应用程序的转移，将逻辑移动到数据库的依赖程度较低，但仍然存在。即使是网络应用程序（取决于语言）也必须编译并发布到网站，这可能会导致停机。

Answer 11

有时，业务逻辑太慢，无法在应用层运行。在客户端功率和带宽更受限制的旧系统上尤其如此。

Answer 12

使用数据库完成工作的主要原因是您只有一个控制点。通常，应用程序开发人员在应用程序的不同部分重用或重写代码片段。即使假设这些都以完全相同的方式工作（这是值得怀疑的），当业务逻辑发生变化时，应用程序需要进行审核，重新编码，重新编译。除非参数发生变化，否则在业务逻辑仅存储在数据库中时不需要这样做。

Answer 13

我的偏好是将任何复杂的业务逻辑保留在数据库之外，仅用于维护目的。如果我在早上2点接到电话，我宁愿调试我的应用程序代码而不是尝试单步执行数据库脚本。

Answer 14

我过去在存储过程中放置​​BL的主要原因是数据库中的事务更容易。

如果您的应用很难部署并且您没有应用服务器，则更改存储过程中的BL是部署更改的最有效方式。

Answer 15

我认为特别针对那些业务（银行业）的旧应用程序，其中业务逻辑很大，几乎不可能在应用程序层中执行所有这些业务逻辑，而且当我们放置这些逻辑时，这是一个很大的性能影响在Application层中，获取数据库的次数越多，导致资源利用率越高（如果在java层中完成，则会有更多java对象）和网络问题，并且忘记了abt性能。

Answer 16

我在一个团队中建立和维护一个相当大的金融系统，我发现没有办法将逻辑放入应用程序层，以便对影响或获得数十万条记录的约束进行操作。

除性能问题外，如果发生错误，纠正存储过程要比调试应用程序，修复，重新编译，重新部署代码以及更长的停机时间快得多