读完这篇文章（业务逻辑数据库或应用层）后，我仍然没有足够的理由去讨论“数据库中的业务逻辑”这个话题。
在我目前的工作中，有很多数据库事务（实际上），所有那些糟糕的代码都很难维护，存储过程中有很多重复，所以如果你想稍微改变一个表中的值，你会需要找到所有这些程序并将它们更改为您想要的。如果您需要稍微更改表格设计，也会发生同样的情况。
当前所有的开发人员都非常了解 SQL，但他们仍然不是任何 DATABASE 作为引擎的专家（8 位开发人员）。
目前我们正计划将整个核心迁移到一个新版本（包括数据库设计）。我需要一些例子：
应用程序语言：Java
数据库：Oracle11g
该应用程序将具有服务，用作 HTTP 页面和 WebServices。
你读过这些 AskTom 主题吗？
他们是汤姆·凯特的好书，充满了伟大的智慧。唯一的麻烦是他们不支持你想要的答案——他们支持相反的观点！
数据层中的业务逻辑通常被认为是邪恶的，原因有几个，我会尽量坚持一般的。
你不能干净地进行单元测试：
单元测试的一般思想之一是不仅要告诉你有问题，还要告诉你问题出在哪里。如果您的 BL 在数据层中并且您的 BL 测试不起作用，您将无法判断问题出在您的逻辑中还是在您的数据中。这会导致更长的调试时间。
存根和模拟整个层：
具有分层结构的主要好处之一是将整个层存根。因此，当您使用存根 DAO 层时，您的逻辑可以单独发展（可能由单独的团队开发），因此您不必担心如何以及从何处获取数据。这使您可以自由地开发您的逻辑，而不必担心您的域模型甚至已经完成。
层级：
如果您的层被干净地分开，那么让它们在单独的物理实例上工作（例如在不同的服务器上）更容易（非常！）。因此，例如，您可以拥有几台服务器来扩展您的数据层（这在 AFAIK 中并不少见）。显然，如果您的逻辑在那里，那将更加困难（如果可能的话）。
蹩脚的代码确实很难维护。这就是糟糕代码的本质——而不是它所在的位置。转向“前端糟糕的代码”解决方案并不是真正的解决方案。
如果您认为数据库结构更改不会影响前端编码的业务逻辑......嗯 - 逻辑不同。
我觉得有些事情在前端处理得很好，有些事情在后端处理得更好。而且我认为在业务对象级别运行的适当 PL/SQL API 设计可以通过将它们与其他层隔离来缓解结构变化问题。
但是，如果有任何支持其他数据库的想法，那么这也是一个有问题的想法，因为并非每个数据库都支持相同的结构。
至于业务逻辑属于哪里 - 这可能完全取决于您的应用程序，实际上，出于性能原因，您可能会发现将其某些方面放在多个层中是有利的。当然，这可能会导致维护问题，但这一切都成为交付项目或产品所必需的权衡的一部分。
但肯定没有一个严格的通用答案。
- 为什么数据库中的业务逻辑有时是邪恶的？
- 数据库中的业务逻辑在何时何地是一个好的实践？
尽可能少。我通常只在应用程序中的实现对数据库性能造成严重影响时才使用它。由于这种原因，在 PL/SQL 中做是更好的选择。
- 为什么应用层中的业务逻辑更适合企业应用。?
答案与第一个答案相同。
这可能是一个糟糕的设计选择（不是邪恶的）
一方面，如果您希望能够迁移到不同的数据库品牌，您不应该将业务逻辑放在存储过程中。
此外，对于复杂的域，在 Java 端使用 OO 模型对域进行建模比在 DB 端更自然。OO 很适合表达抽象和它们之间的关系。
关于该主题的规范书籍是领域驱动设计。
留在数据库方面的一个原因可能是性能。如果您有大量业务数据，在应用程序中检索和操作它可能不够高效。对于批处理尤其如此。
数据库中业务逻辑的问题是
好处是
我曾在一家拥有数据库中所有逻辑的保险公司工作过，它非常好，但非常昂贵。我认为您的问题的任何答案都将非常抽象，因为要做出这样的重大架构决策需要考虑很多要点。
为什么数据库中的业务逻辑有时是邪恶的？您必须完成每个供应商的每次更新，如果您想将支持从一个供应商转移到另一个供应商，就会遇到麻烦。如其中一篇文章所述，价格昂贵。
数据库中的业务逻辑在何时何地是一个好的实践？通过不涉及业务逻辑的存储过程更新或删除外键或相关行的逻辑应该没问题。
为什么应用层中的业务逻辑更适合企业应用。? 从易于维护开始，应用程序层可以利用框架，为您节省大量时间和金钱，而不是重新发明轮子。利用用于应用程序层的线程或语言特定功能。