我讨厌再次提出“数据库与代码中的业务逻辑”这一经典问题，但我需要一些具体的理由来说服开发人员团队，他们认为代码中的业务逻辑更好，因为它更易于维护，最重要的是。我以前在DB中有很多业务逻辑，因为我认为它是单点访问。如果我是唯一一个改变它的人，那么维护很容易。根据我的经验，当项目变得更大和更复杂时，问题就出现了。 DB存储过程的源控制不像新IDE那样先进，编辑也不是。代码中的业务逻辑可以比DB更好地扩展，这是我在最近的经验中发现的。
所以，只是搜索一下stackoverflow，我发现了与其尊敬的成员相反的哲学：
https://stackoverflow.com/search?q=business+logic+in+database
我知道对于任何情况都没有绝对的，但是对于给定的asp.net解决方案，它将使用sql server或oracle，对于不是特别高的流量站点，为什么我会将逻辑放在DB中？
答案 0 :(得分：6)
取决于您所谓的业务。
数据库应该按预期进行。
如果数据的使用者和提供者希望数据库做出某些保证，那么就需要在数据库中完成。
有些人不在数据库中使用参照完整性，并期望系统的其他部分对其进行管理。有些人直接访问数据库中的表。
我觉得从系统和组件的角度来看，数据库就像任何其他服务或类/对象一样。它需要保护其周边，隐藏其实施细节并提供完整性保证，从低级完整性到一定级别，这可能被视为“业务”。
执行此操作的好方法是引用完整性，存储过程，触发器（必要时），视图，隐藏基表等等。
答案 1 :(得分：1)
数据库可以处理数据，为什么要权衡已经受到重创的内容很难为您提供数据。这是一个表演的东西和一个代码的东西。维护业务逻辑代码比将数据全部存储在数据库中要容易得多。 Sprocs，Views和Functions只能到目前为止，直到你有了sprocs视图视图来填补这些混乱。通过业务逻辑，你可以分离你的烦恼。如果你有一个导致计算错误的错误，那么检查业务逻辑代码比进入数据库更容易，看看是否有人搞砸了存储过程中的某些东西。这是高度自以为是，在某些情况下可以在数据库中放入一些逻辑但我对此的想法是它是一个数据库而不是逻辑库，把它们放在它们所属的位置。
P.S：可能会为这篇文章吸引一些热情，这是高度自以为是的，除了表现数字之外，没有任何真实的证据，它就成了你正在做的事情。 编辑：凯德提到我忘记的事情。 Refrential完整性。无论如何，请在数据库中保持正确的数据完整性，没有孤立的记录ON DELETE CASCADE，检查等等。答案 2 :(得分：-1)
我在一个巨大的项目中遇到过数据库逻辑。这是由DBA专家的主要经理的决定引起的。他说应用程序应该是轻量级的，它应该对数据库方案，连接表等一无所知，并且无论如何存储的Procs的执行速度比来自客户端的事务范围和查询要快得多。 另一方面，我们对数据库对象映射存在太多错误（存储的prod或基于其他视图的视图等视图）。无法理解我们的数据发生了什么，因为点击的每个按钮都被称为一个巨大的存储过程，其中包含70-90-120个参数并更新了几个（10-15）表。我们没有能力查询简单的选择请求所以我们必须编译一个视图或存储Proc和类的代码，这只是为了一个简单的连接:-（当然，当表或视图定义更改时，您应该重新编译所有其他dB对象在其他地方的编辑对象上，您将获得运行时异常。 所以我认为数据库中的逻辑是一种可怕的方式。当然，如果性能或安全性问题需要，你可以在存储过程中存储一些代码片段，但是你不应该在数据库中开发所有东西）逻辑应该是灵活的，可测试的和可维护的，并且你不能使用数据库来达到这一点。存储逻辑）