我讨厌再次提出“数据库与代码中的业务逻辑”这个经典问题，但我需要一些具体的理由来说服一个老的开发团队，他们认为代码中的业务逻辑更好，因为它更多可维护，高于一切。我曾经在数据库中有很多业务逻辑，因为我相信这是单点访问。如果我是唯一一个改变它的人，维护很容易。根据我的经验，当项目变得越来越大和复杂时，问题就出现了。数据库存储过程的源代码控制并不像新IDE那样先进，编辑也没有。代码中的业务逻辑可以比数据库更好地扩展，这是我在最近的经验中发现的。数据库层中的业务逻辑
所以，就在计算器搜索，我发现从它的尊贵会员完全相反的理念：
https://stackoverflow.com/search?q=business+logic+in+database
我知道没有绝对的任何情况，但对于给定的asp.net的解决方案，这将使用sql服务器或oracle，为一个不是特别高的流量站点，为什么我会把逻辑放在数据库中？
取决于你所谓的业务。
数据库应该做预期的工作。
如果消费者和数据提供者期望数据库做出某些保证，那么它需要在数据库中完成。
有些人不在数据库中使用参照完整性，并期望系统的其他部分管理它。有些人直接访问数据库中的表。
我觉得从系统和组件的角度来看，数据库就像任何其他服务或类/对象一样。它需要保护它的边界，隐藏其实施细节，并提供完整性保证，从低级完整性到可能被认为是“商业”的某个级别。
好办法做到这一点是引用完整性，存储过程，触发器（在必要时），视图，隐藏基表，等等等等
数据库处理数据的事情，为什么要衡量一些已经非常难以提供数据的东西。这是一个性能和代码的事情。维护业务逻辑代码比将其全部存储在数据库中要容易得多。 Sprocs，视图和函数只能运行到目前为止，直到你有视图视图与sprocs填补混乱英寸与业务逻辑，你分开你的忧虑。如果你有一个导致错误计算的错误，检查业务逻辑代码比进入数据库更容易，看看是否有人在Stored Procedure中搞砸了某些东西。这是非常有见地的，在某些情况下可以在数据库中放入一些逻辑，但是我的想法是它是一个数据库而不是逻辑库，把它放在他们所属的地方。
P.S：可能会为这篇文章吸引一些热度，它的评价很高，除了表现数字之外，没有任何实际的证据，它会成为您正在使用的内容。
编辑：凯德提到我忘了的东西。充分的完整性。通过一切手段，请在你的数据库中有正确的数据完整性，没有孤立的记录ON DELETE CASCADE的，检查和什么。
是的，我知道:)。当数据库比框架执行速度快得多时，整个'数据库中的业务逻辑'是一个较老的哲学（或者我认为）。今天的框架更好，更快，更灵活，更具可扩展性，所以我不认为这种哲学占上风。但我在stackoverflow上的搜索似乎表明，否则...... –
@ M.R。我自己有点震惊。我已经在许多地方完成了性能测试，以阻止这种做法，因为它正在让数据库陷入困境，从而在那里做了很多逻辑。 .NET框架（现在非常流行）非常快，因为PHP非常常用于DB后端。没有理由真的把更多的工作放到数据库上（至少我是这么认为的）。 –
我还会注意到许多“开发人员”实际上并不擅长编写SQL。因此，他们放在数据库中的“逻辑”可能表现不佳，他们将这归咎于数据库而不是他们使用的技术。过度使用触发器，几乎所有游标的使用，由于误解可控性而引起的低效查询，以及基本的索引策略都在这里起作用。 –
我都面临着数据库逻辑上的大型项目之一。这是由主要经理谁是DBA专家的决定造成的。他说应用程序应该是轻量级的，它对数据库方案，连接表等应该一无所知，并且无论如何，存储Procs的执行速度要比客户端的事务范围和查询快得多。 另一方面，我们有太多的数据库对象映射错误（基于其他视图的基于视图的存储prod或视图等）。无法理解我们的数据正在发生什么，因为每次点击按钮都会调用70-90-120个参数的巨大存储过程并更新几个（10-15）表。我们没有能力去查询简单的select请求，所以我们不得不编译一个视图或者在代码中存储Proc和类，只是为了一个简单的连接:-(当然，当表或视图定义改变时，你应该重新编译所有其他基于dB的对象在编辑的对象上你会得到运行时异常 所以我认为数据库中的逻辑是一种可怕的方式当然，如果需要性能或安全问题，你可以在存储过程中存储一些代码片段，但是你不能开发一切数据库）逻辑应该是灵活的，可测试和可维护的，并且你不能使用数据库来存储逻辑的这一点）
感谢您的回答 - 虽然我的意思是业务逻辑，但我更多地指的是非常具体的业务逻辑，例如“该员工是否允许为该部门增加费用”......参考完整性和触发器可以帮助我保护孤立的数据和保存外键，但它不会帮助我做像我提到的检查。哪里应该这样？ –
@Cade我完全同意你的看法，只不过如果你隐藏太多或者做了太多的视图，Sprocs很容易变得几乎不可管理。我已经看到重构视图之上的视图和用于管理一切的存储过程的情况。好的设计可能会阻止很多这种情况，这就是为什么三层和n层架构被发明出来的原因。尝试并避免很多这些问题。 –
@ M.R。关于员工和部门的情况很可能是数据库外部的情况。另一方面，如果可能有多个应用程序可能正在执行插入操作（例如来自SSIS包的订单，Web前端和Windows服务），则很可能您希望数据库执行该操作，或者通过某种应用程序服务器或Web服务强制所有用户。 –