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

假设我在

表1

中有一项

A、B、C

。 它们都有属性

f1

。但是，

A

和

B

具有

f2

，这不适用于

C

。

表1

将设计为：

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

将有另一个表

表2

包含

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

上面只是在DB或代码中放置此类业务逻辑约束的示例

---

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

关于第二个建议：您通常也可以在表中查询~NULL值，这与添加和设置布尔属性相同（最好考虑冗余）。这也是检测表是否“损坏”的方法。但是，您也可以通过从表2中收集所有“itemName”条目来启动查询，可能与表1建立一个交集，并将感兴趣的案例插入表1中：

1.) Intersect the "itemName" from table1 and table2 => table3
2.) Join the table3 and table2 on "itemName", "f2" => insert each tuple into table1

---

或者，您也可以将表1拆分为两个表{“itemName”、“f1”}和{“itemName”、“f2”}，这将消除您的问题。

因为这基本上是一个字段验证（

MyModel

可以将属性f2设置为NULL（不存在）”），我会说，您必须在模型的验证器中执行此操作

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

我使用的规则如下：数据库用于存储模型数据。如果可能，您应该尝试不存储任何其他内容，只存储数据。在您的情况下，

has_f2

不是一个数据，而是一个业务规则

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