看完这篇文章(business logic database or application layer）我还没有足够的理由去对抗“数据库中的业务逻辑”主题。在哪里放置业务逻辑，AppLayer或DataLayer？
在我目前的工作中，有很多db事务（实际上）和所有那些蹩脚的代码很难维护，存储过程中有很多重复，所以如果你想在表中改变一个值位，你需要找到所有这些程序并将它们改为你想要的。如果您需要更改一些桌面设计，也会发生同样的情况。
所有当前的开发人员都非常了解SQL，但他们仍然不是任何DATABASE中的专家（8位开发人员）。
目前我们正计划将整个核心迁移到新版本（包括数据库设计）。我需要一些例子的：
应用程序语言：Java的
数据库：Oracle11g的
应用程序将有服务，担任HTTP网页和Web服务。
蹩脚的代码确实难以维护。这是糟糕的代码的本质 - 而不是它所在的位置。转向“前端糟糕的代码”解决方案并不是真正的解决方案。
如果您认为数据库结构变化不会影响在前端编码的业务逻辑...... ummm - 逻辑规定不同。
我认为有些东西在前端处理得很好，有些东西在后端处理得更好。我认为，在业务对象级别运行的正确的PL/SQL API设计可以通过将结构变化问题与其他层隔离来缓解结构变化问题。
但是，如果有任何想法支持其他数据库，那么这也是一个有问题的想法，因为不是每个数据库都支持相同的构造。
至于业务逻辑所属的地方 - 这可能完全取决于您的应用程序，事实上，出于性能方面的原因，您可能会发现在多层中具有某些方面是有利的。当然，这可能会导致维护问题，但这一切都成为交付项目或产品所必需的权衡的一部分。
但是肯定没有一个严格的普遍答案。
首先，如果您希望能够迁移到不同的数据库品牌，则不应该在存储过程中拥有业务逻辑。
此外，对于复杂领域，使用OO模型对Java进行建模比在DB方面更自然。 OO很适合表达抽象和它们之间的关系。
该主题的规范书是Domain Driven Design。
留在数据库方面的原因可能是性能。如果您的业务数据量很大，则可能效率不够，无法在应用程序中检索和操作它。批处理尤其如此。
你读过这些AskTom主题吗？
他们是很好的阅读和充分的汤姆·凯特大智慧。唯一的麻烦是他们不支持你想要的答案 - 他们支持相反的观点！
希望Tom Kyte不会建议Oracle/PLSQL为最佳解决方案，这是非常天真的想法。 – 2015-11-25 02:17:51
与数据库中的业务逻辑的问题是
的好处是
我曾经为一家拥有数据库中所有逻辑的保险公司工作，这很不错，但非常昂贵。我认为针对你的问题的任何回答都将是非常抽象的，因为要做出这样的大型架构决策需要考虑许多要点。
你从哪里得到了7.5万美元？我希望你不支付EE列表价格（47.5K）和使用16个单核心处理器。 :) – 2011-03-03 00:15:52
如果您需要扩展，您需要EE版本，具有真正的应用程序群集+支持。这是每个处理器80万美元，加上其他额外功能。 – Augusto 2011-03-03 09:43:15
数据层中的业务逻辑通常被认为是邪恶的，原因有几个，我会试着坚持一般的原则。
你不能干净单元测试：
一个单元测试的总体思路是，不仅告诉你有问题，但也说不出哪里出了问题。如果您的BL处于数据层，并且您的BL测试不起作用，则无法确定问题出在您的逻辑还是数据中。这导致更长的调试时间。
成株和嘲笑整个层：
一个具有将被磕碰整个层的分层结构的主要优点。因此，当您使用存根DAO层时，您的逻辑可以单独演变（也许由单独的团队开发），因此您不担心如何以及从哪里获取数据。这使您可以自由地开发自己的逻辑，而无需担心域模型甚至尚未完成。
层级：
如果你的层分离干净的多（多！），更容易让他们在不同的物理实例的工作（在不同服务器上的实例）。因此，举例来说，你可以有几台服务器来扩展你的数据层（这是非常罕见的AFAIK）。显然，如果你的逻辑在那里会更难（如果可能的话）。
+1单元测试的好处。 – 2011-03-02 16:34:09
“数据层”和“存储过程”有所不同。 “数据层”之上的存储过程中有单独的处理层是完全可能的。 – 2011-03-02 17:10:40
据我了解这个问题。在给定的应用程序中，“数据层”是存储过程，其中也存在一些业务逻辑。 – Simeon 2011-03-02 17:13:05
为什么数据库中的业务逻辑有时候是EVIL？ 您必须完成每个供应商的每个更新，如果您想要将支持从一个供应商转移到其他供应商，则必定会遇到麻烦。如帖子中提到的那样昂贵。
数据库中的业务逻辑是多少和什么时候是一个好习惯？ 通过存储过程来更新或删除外键或相关行的逻辑应该没有问题。
为什么应用层中的业务逻辑更适合企业应用。 ？ 好吧，从容易维护开始，应用层可以利用框架，为您节省大量的时间和金钱，而不是重新发明轮子。利用线程或用于应用程序层的语言特定功能。
+1为“不要重新发明轮子” – 2011-03-02 16:42:46
我不清楚什么“框架”与业务逻辑有关，也不知道为什么存储过程涉及“重新发明轮子”。有人可以用一个例子来详细说明吗？ – 2011-03-02 17:08:12
数据库独立性非常小。当一家公司为Oracle许可证支付大笔资金时，如果有人选择将其丢弃并使用MS SQL，那么您并不高兴。 – SPee 2011-03-02 17:23:41
- 为什么数据库中的业务逻辑有时候是EVIL？
- 多少时间和什么时候业务逻辑 数据库是一个很好的做法？
尽可能最小。我通常只在应用程序中的实现需要严重的数据库性能时才使用它。出于这种原因，在PL/SQL中执行它是一个更好的选择。
-为什么应用层中的业务逻辑更适合企业应用。 ？
答案与第一个答案相同。
这可能是一个糟糕的设计选择（不做恶）如果
在我看来，迄今为止所有的答案（包括我的！）都没有给出问题的例子。他们大多只是重申您所链接的线索中提出的感知问题，没有任何可以讨论的支持示例。例如“你不能单元测试干净”：我想看一个具体的例子。 – 2011-03-02 17:17:10
如果您没有足够的理由来对抗数据库中的“业务逻辑”，那么可能是因为您的情况没有足够的理由，而且这可能是正确的做法。我建议你问自己，如果你没有理由，你为什么要争辩。 – 2011-03-02 22:27:39