数据模型逻辑是否应该存在于数据库模式中？

Question

(抱歉，如果我的一些术语过时了，我在这个问题上看得不多，我正在用我能想到的最好的术语)

数据模型逻辑是否应该存在于数据库模式中？

在这里，我要区分业务逻辑和数据模型逻辑。所谓数据模型逻辑，我指的是与数据完整性特别相关的事情，比如级联删除(ex )。删除客户还应该删除所有客户地址，删除用户应该删除该用户的所有组成员)，而不是更高级别的业务逻辑和规则。我已经阅读过"数据库应该实现多少业务逻辑？“和"业务逻辑:数据库与代码”，并且完全同意普遍的共识，即业务逻辑应该存在于代码中，而不是数据库中。

我有一部分喜欢数据库执行数据模型的结构规则的想法。可以说，这是一个数据库问题。它可以简化代码方面的事情；您只需删除主实体本身，数据库就会自动处理适当的清理。如果有任何事情绕过应用程序并直接访问数据库(例如)，它将有助于加强数据结构。通过SQL进行手动更改，通过ETL类型存储过程从另一个源提取数据)。

但我的另一半觉得这是错误的方法。现在，应用程序代码必须假定数据库将正确处理这一问题。如果有数据模型逻辑问题出现，不能由数据库和简单的约束处理，那么现在您可以看到数据模型逻辑存在于两个不同的位置:一些在代码中，一些在数据库中。如果您选择将数据存储更改为其他存储，那么现在必须在新的存储系统上重新实现相同的逻辑。

Answer 1

是!

为什么？因为独特的约束符合每个人的最佳利益。

当然，有些人可能会争辩说，应用程序可以做到这一点，甚至可能有需要暂时违反唯一约束的用例。

对此，我说，“这不是唯一的约束！”

当然，这不仅仅是一种独特的约束。只是个简单的例子。

数据库不应该是应用程序的中心。但它应该是对其本身有意义的东西的控制权威。我不告诉文件如何分配自己在硬盘上完全相同的原因。

这是一条可以被模糊和滥用的界线。关键是使用数据库只强制执行使数据库可靠有用所需的规则(无论任何应用程序试图做什么)。不要以任何可能的方式使用数据库。

我喜欢DB的说法，“好吧，我不知道你在做什么，但那只是胡说八道”。

至于级联删除，这是一个灰色区域。在对象世界中，我们讨论合成与聚合。聚合来来去去，但是如果您是由一些东西组成的，您需要它，这样您就可以正确地工作了。它的一生与你的交织在一起。至少，如果你不想抛出异常，因为当你处于糟糕的状态时，有东西试图利用你，至少应该是这样。

然而，在数据库世界中，这是数据。如果你删除了一个客户，这是否意味着你从来没有卖东西给这个客户？您是否可以删除与我们有销售记录的客户？

这是一个关系约束，仅仅是因为业务需要。该数据库可以很好地存储与客户的事务记录，客户现在只不过是一个外键号码。企业为什么要删除客户记录，这是任何人的猜测。也许法律团队向IT团队挥动着法庭命令。这可能会打破一些报告，但这是它的方式。

现在，如果表A_audit是表A中所有东西的历史，那就是数据库业务。没有比这类事情更有权威的了，因为这是数据库的工作。因此，在这里执行级联删除的数据库是有意义的，当它被调用时。也许有些数据是你不该收集的。现在它需要被删除。

当然，这一切都取决于您使用delete来表示什么。这仍然是一个数据模型。所以，不仅有一个理由可以删除这些东西。这就是事情变得棘手的地方。

就我个人而言，我更喜欢CR而不是UD。令人惊讶的是，你能做这么多事情。但我们的理想很少是我们的成就。