数据库中的业务逻辑与代码？
作为一名软件工程师，我倾向于在应用程序层中编写业务逻辑，而通常只依赖于数据库而不是CRUD（创build检索更新和删除）操作。 另一方面，我运行的应用程序（通常是较旧的），其中大量的业务逻辑是用存储过程编写的，所以有人喜欢在数据库层中编写业务逻辑。
对于在存储过程中拥有和/或享有写/写业务逻辑的人，您使用这种方法的原因是什么？
我试图严格限制我在数据库中的业务逻辑，只处理必须做很多查询和更新来执行单个应用程序操作。 有人可能会争辩说，即使这应该是在应用程序，但我喜欢保持IO下来，如果我可以。
数据库对于CRUD来说是非常好的，但是如果它们被逻辑臃肿的话：
- 逻辑的地方会变得混乱，
- 通常情况下，数据库是一个孤岛，并不像应用程序服务器那样横向扩展。
- t_sql / PLsql很难阅读和程序性质
- 你放弃了OOAD的所有好处。
尽最大可能将您的业务逻辑保持在最可testing和可debugging的环境中。 在其他人现有的答案中，将数据库中的业务逻辑存储在数据库中有一些正当的理由，但几乎总是远远超过这个原因。
将业务逻辑限制到应用程序层是短视的。 有经验的专业数据库devise师很less在系统上使用它。 数据库需要有约束和触发器以及存储过程来帮助定义来自任何源的数据如何进入它。
如果数据库要保持其完整性并确保所有新数据或数据更改的来源遵循规则，那么数据库就是放置所需逻辑的地方。 把它放在应用程序层是一个等待发生的数据噩梦。 数据库不能从一个应用程序获取信息。 应用程序中的业务逻辑常常被import无意中绕过（假设您有一位新客户希望他们的旧历史数据导入您的系统或大量目标logging，没有人会通过界面input一百万个可能的目标，它会在导入时发生）。也可以通过在查询窗口中修改一次性问题（例如将所有产品的价格提高10％）来绕过它。 如果你有应用层的逻辑应该已经应用到数据的变化，它不会。 现在可以将它放在应用程序层中，没有任何意义的将错误的数据发送到数据库并浪费networking带宽，但是不能将其放入数据库迟早会导致数据问题。
将所有这些都保存在数据库中的另一个原因是用户有可能犯下欺诈行为。 如果你把所有的逻辑放在应用层，那么你必须授予用户直接访问表的权限。 如果你把所有的逻辑封装在存储过程中，他们可以被限制在只做存储过程允许的内容，而不是其他任何东西。 我不会考虑允许用户访问存储财务logging或个人信息（如健康logging）的数据库，因为我不允许任何人，除了几个dbas以任何forms或forms直接访问生产logging。 更多的欺诈行为比许多开发者意识到的要多，他们几乎没有一个人在devise中考虑过这种可能
如果您需要导入大量数据，则通过数据访问层可能会导致导入变慢，因为它并不需要数据库旨在处理的基于集合的操作的优势。
您对“业务逻辑”这个术语的使用是相当模糊的。
它可以被解释为意味着包括数据约束的强制执行（又名“业务规则”）。 这些明确的执行属于dbms时期。
它也可以被解释为包含诸如“如果一个新客户到达，然后在一个星期内，我们寄给他一封欢迎信”。 试图在数据层推送这样的东西可能是一个很大的错误。 在这种情况下，“创build一个新的欢迎信”的驱动程序应该可能是触发新客户行插入的应用程序。 想象一下，每一个新的数据库行插入触发一个新的欢迎信，然后突然我们接pipe另一个公司，我们必须将该公司的客户集成到我们自己的数据库中… Ouch。
在适当的情况下，我们会在数据库层面进行大量的处理。 有很多操作你不想把大数据集拉回应用层进行分析。 这对我们来说也是一个更简单的部署 – 与所有安装点上的更新应用程序相比，这是一个重点 但很多取决于你的应用程序和它的function; 这里没有一个好的答案。
在几个话题中，我把“逻辑”放在了sprocs中，因为CRUD可能在多个地方发生。 通过“逻辑”我不得不说，这不是真正的业务逻辑，而是更多的“完整性逻辑”。 它可能是相同的 – 如果某些方法被删除或更新，某些清理可能是必要的，如果这个删除或更新可能来自多个不同代码库的工具，那么把它放在proc中是有意义的。全部使用。
另外，有时候“业务逻辑线”也很模糊。 以报告为例，他们可能依赖于存储过程或视图，这些存储过程或视图封装了对模式对业务意味着什么的“聪明”。 你经常看到CASE语句和基于列值或其他批评的“做事情”？ 可以被解释为业务逻辑，但它可能属于DB可以优化，等等。
我会说，如果“业务逻辑”是指应用程序stream，用户控制，定时操作和一般“做生意的东西”，那么它应该在应用程序层。 但是，如果这意味着确保无论数据如何被挖掘，它总是有意义的，而且是一个明智的，非自相矛盾的整体，那么执行这些规则的检查就会进入数据库，绝对没有问题。 总是有很多方法将数据推送到数据库中，并在数据库中进行操作。 并不是所有这些方式都有“商业逻辑”。 你会发现一个SQL会话通过一个支持电话上的DOS窗口在上午3点是非常自由的，它允许例如！ 如果逻辑不在数据库中，以确保所有的数据更改是有意义的，你可以肯定的是，随着时间的推移，数据将非常非常非常搞砸。 而且，由于系统只与其所拥有的数据一样有价值，因此投资回报率要低得多。
您经常在数据库层find业务逻辑，因为进行更改和部署通常会更快。 我认为最好的意图不是把逻辑放在那里，而是因为部署的简单性，它最终会在那里结束。
将业务逻辑放在数据库中的两个很好的理由是：
- 它将您的逻辑和数据与可能访问不实现类似逻辑的数据库的其他应用程序相连。
- 数据库devise通常比应用程序层更加活跃，并且减less了在客户端迁移到新技术时所需的工作。
我为一家金融型公司工作，其中某些规则是由州来实施的，而且这些规则和计算方法如果不是每周都可能几乎每天都在变化。 既然如此，把处理计算的逻辑部分移到数据库就更有意义了。 在那里可以testing和应用更改，而无需重新编译和重新分配应用程序，这是不可能每天不干扰业务的。 存储的过程经过testing，批准和应用，最终用户不会更聪明。 随着向基于networking的应用程序的转移，将逻辑移至数据库的依赖程度较低，但仍然存在。 即使是networking应用程序（取决于语言）也必须编译并发布到可能导致停机的网站。
有时业务逻辑太慢，无法在应用层上运行。 在客户端功率和带宽更有限的旧系统上，情况尤其如此。
使用数据库来完成这项工作的主要原因是你有一个单一的控制点。 通常，应用程序开发人员在应用程序的不同部分重新使用或重写代码片段。 即使假设这些工作都是以完全相同的方式工作（这是值得怀疑的），当业务逻辑发生变化时，应用程序需要被重新编译，重新编码。 除非参数发生变化，否则在业务逻辑仅存储在数据库中的情况下，这是不必要的。
我的首选是将任何复杂的业务逻辑保留在数据库之外，仅用于维护目的。 如果我在凌晨2点接到电话，我宁愿debugging我的应用程序代码，而不是尝试通过数据库脚本。
我以前把BL放在存储过程中的主要原因是数据库中的事务更容易。
如果您的应用程序难以部署，并且您没有应用程序服务器，则更改存储过程中的BL是部署更改的最有效方式。
我认为对于那些Bussiness逻辑非常庞大的旧版应用程序，我们几乎不可能在应用程序层中执行所有这些业务逻辑，而且当我们把这些逻辑放到应用程序层时，这是一个巨大的执行力在数据库访问次数更多的情况下，会导致更多的资源利用率（更多的Java对象，如果在Java层完成的话）和networking问题，并忘记abt的执行。
我正在一个团队中build立和维护一个相当大的金融系统，我发现没有办法将逻辑放到应用层中去执行，影响到数十万条logging或从中获得约束。
除了性能问题之外，如果发生错误，纠正存储过程比debugging应用程序快得多，修复，重新编译，重新部署代码的时间更长
