数据库层的业务逻辑

Question

我讨厌再次问“数据库中的业务逻辑与代码中的业务逻辑”的经典问题，但我需要一些具体的理由来说服老的开发人员团队，代码中的业务逻辑更好，因为它更容易维护。我曾经在数据库中有很多业务逻辑，因为我相信它是单一访问点。如果我是唯一一个修改它的人，那么维护就很容易了。根据我的经验，当项目变得更大、更复杂时，问题就出现了。DB存储的Proc的源代码控制没有较新的IDE的那么高级，编辑器也不是。在我最近的经验中，我发现代码中的业务逻辑可以比数据库中的业务逻辑扩展得更好。

所以，在stackoverflow周围搜索，我发现了与其尊敬的成员截然相反的哲学：

https://stackoverflow.com/search?q=business+logic+in+database

我知道对于任何情况都没有绝对的解决方案，但是对于一个给定的asp.net解决方案，它将使用sql server或oracle，对于一个不是特别高流量的站点，我为什么要把逻辑放在数据库中？

Answer 1

这取决于你所说的商业。

数据库应该执行预期的操作。

如果数据的使用者和提供者期望数据库做出某些保证，那么它需要在数据库中完成。

有些人不在他们的数据库中使用引用完整性，并期望系统的其他部分来管理它。有些人直接访问数据库中的表。

我觉得从系统和组件的角度来看，数据库就像任何其他服务或类/对象。它需要保护自己的边界，隐藏其实现细节，并提供完整性保证，从低级别的完整性一直到一定的级别，这可能被认为是“业务”。

实现这一点的好方法是引用完整性、存储过程、触发器(必要时)、视图、隐藏基表等。

Answer 2

数据库做数据的事情，为什么要压低已经受到很大冲击的东西来给你数据呢？这是一个性能问题和代码问题。维护业务逻辑代码要比将其全部存储在数据库中容易得多。Sprocs、视图和函数只能走到这一步，直到您有了带有sprocs的视图视图来填补这一混乱。有了业务逻辑，您就可以分离您的担忧。如果您有一个导致计算错误的bug，那么检查业务逻辑代码比进入DB并查看是否有人在存储过程中搞乱了什么更容易。这是非常固执己见的，在某些情况下，在数据库中放入一些逻辑是可以的，但我的想法是这是一个数据库，而不是逻辑库，把东西放在它们属于它们的地方。

附注:这篇文章可能会引起一些关注，它是非常固执己见的，除了性能数字之外，没有任何真实的证据，这就成为了你正在处理的一个案例。

编辑: Cade提到的一些我忘记了的事情。引用完整性。无论如何，请在您的数据库中有正确的数据完整性，没有删除级联，检查和诸如此类的孤立记录。

Answer 3

我曾经在一个大型项目中遇到过数据库逻辑。这是由作为DBA专家的主经理的决定造成的。他说，应用程序应该是轻量级的，它应该对数据库方案，连接表等一无所知，而且无论如何，存储过程的执行速度都比来自客户端的事务范围和查询快得多。另一方面，我们在数据库对象映射(存储的产品或基于视图的视图，基于其他视图等)方面有太多的错误。我们无法理解我们的数据发生了什么，因为每个点击的按钮都调用了一个巨大的存储过程，其中包含70-90-120个参数并更新了几个(10-15)表。我们没有能力查询简单的select请求，所以我们不得不为一个简单的连接编译一个视图或存储的过程和代码中的类:-(当然，当表或视图定义发生变化时，您应该重新编译所有其他基于编辑的对象的dB对象，您将在其他地方得到运行时异常。所以我认为数据库中的逻辑是一种可怕的方式。当然，如果性能或安全问题需要，你可以将一些代码存储在存储过程中，但你不应该在数据库中开发所有的代码)逻辑应该是灵活的、可测试的和可维护的，而使用数据库来存储逻辑是达不到这一点的)