我不想再问“数据库中的业务逻辑与代码中的业务逻辑”这个经典问题，但我需要一些具体的理由来说服老开发团队代码中的业务逻辑更好，因为它更易于维护，最重要的是.我以前在数据库中有很多业务逻辑，因为我认为这是单点访问。维护很容易，如果我是唯一一个进行更改的人的话。根据我的经验，当项目变得更大更复杂时，问题就来了。 DB Stored Procs 的源代码控制不如较新的 IDE 的源代码控制先进，编辑器也没有。代码中的业务逻辑可以比数据库中的业务逻辑更好地扩展，这是我在最近的经验中发现的。
所以，只要搜索一下 stackoverflow，我就发现了与其尊敬的成员截然相反的理念:
https://stackoverflow.com/search?q=business+logic+in+database
我知道任何情况都没有绝对的，但是对于一个给定的 asp.net 解决方案，它将使用 sql server 或 oracle，对于一个不是特别高流量的站点，我为什么要把逻辑放在数据库中？
最佳答案
取决于您所说的业务。
数据库应该做预期的事情。
如果数据的消费者和提供者希望数据库做出一定的保证，那么就需要在数据库中完成。
有些人不在他们的数据库中使用引用完整性，并期望系统的其他部分来管理它。有些人直接访问数据库中的表。
我觉得从系统和组件的角度来看，数据库就像任何其他服务或类/对象。它需要保护其边界、隐藏其实现细节并提供完整性保证，从低级别完整性到特定级别，这可能被视为“业务”。
做到这一点的好方法是参照完整性、存储过程、触发器(必要时)、 View 、隐藏基表等等。
关于sql-server - 数据库层的业务逻辑，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7005404/