Question

假设我在A,B,C中有一个项Table1。它们都具有属性f1。但是，A和B的{{1}}不适用于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中没有C的记录，我无法区分它是否是损坏的表或事实Table2只是没有属性C。

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

f2

或者 2.在if (iteaName == C ) "Do not search Table2" else (search Table2) if (No record) return "Corrupted Table"中添加另一个bool字段"having_f2"，以帮助确定Talbe1不适用于C.

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

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

Answer 1

由于这基本上是字段验证（“如果MyModel可以将属性f2设置为NULL（不存在）”），我会说，你必须在模型的验证器中执行此操作。

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

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

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

Answer 2

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

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

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

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

2 个答案: