database - 数据库应该包含一些业务逻辑吗？

Question

假设我在 Table1 中有一个项目 A,B,C。它们都具有属性 f1。但是，A 和B 有f2 不适用于C。Table1 将设计为:

    itemName      f1       f2 
------------------------------------
       A           100     50
       A           43      90
       B           66      10
       C           23     

还有另一个表 Table2 包含 f2 的所有可能值:

    itemName      f2(possible value)      
------------------------------------
       A           50      
       A           90
       A           77
       B           10      

假设现在我想将具有最高值f2 的记录添加到Table1 中，这取决于iteaName。 A 和 B 一切正常。但是在 C 的情况下，当我循环遍历 Table2 时，因为 Table2 中没有 C 的记录，我无法区分它是损坏的表还是 C 只是没有属性 f2。

我能想到的解决这个问题的唯一方法是:1.在代码中添加约束，如:

   if (iteaName == C )
       "Do not search Table2"
   else (search Table2)
       if (No record)
          return "Corrupted Table" 

或者2. 在 Talbe1 中添加另一个 bool 字段 "having_f2" 以帮助识别 f2 不适用于 C。

以上只是在数据库或代码中放置此类业务逻辑约束的示例。

您能否就以上两种意识形态之间的权衡给我更多的意见？换句话说，哪个更有意义。

Answer 1

因为这基本上是一个字段验证(“如果 MyModel 可以将属性 f2 设置为 NULL(不存在)”)，我会比如，您必须在模型的验证器中执行此操作。

只有在不可能的情况下，才向模型表中添加一些列。

我使用的规则如下:数据库用于存储模型数据。如果可能的话，除了数据，你应该尽量不存储任何其他东西。在您的情况下，has_f2 不是数据，而是业务规则。

当然，这条规则也有异常(exception)。例如，有时业务逻辑必须由用户控制，在这种情况下将其存储在数据库中是完全可以的。