在不牺牲关系数据库中数据一致性的情况下解决超类型-子类型关系

Question

为了更好地设计数据库，我注意到我总是被困在试图解决完全相同问题的变体中。

以下是使用常见要求的示例：

1. 一家在线商店销售不同类别的product.
2. 系统必须能够检索所有产品类别的列表，例如food和furniture。
3. 客户可以订购任何产品并检索他的order历史记录。
4. 系统必须根据产品类别存储特定属性；说expiration_date和calories任何food产品和manufacture_date任何furniture产品。

如果不是需求 4，模型可能非常简单：

问题是试图解决需求 4。我想到了这样的事情：

在这种方法中，关系product-furniture和product-food是超类型-子类型（或超类-子类）关联；子类型的主键也是超类型主键的外键。

但是，这种方法不能保证category通过外键引用的product将与其实际子类型一致。例如，没有什么能阻止我将foodcategory设置为Furniture表中具有子类型行的产品元组。

我阅读了有关建模关系数据库中的继承的各种文章，尤其是这篇和这篇非常有帮助但由于上述原因没有解决我的问题的文章。但是无论我使用什么模型，我都不会对数据一致性感到满意。

如何在不牺牲数据一致性的情况下解决需求 4？我在这里做错了吗？如果是这样，根据这些要求解决此问题的最佳方法是什么？

Answer 1

我认为数据库不应该负责阻止某人对记录的子类型进行错误分类。这看起来更像是业务逻辑层问题。所以，我认为你的第二种情况没有太大问题。我发现它甚至在非常大型的企业解决方案中也能很好地工作。

在大表大小（例如 200 万或更大）下，如果您需要连接超过几千个结果，则组合子类和超类所需的 JOIN 查询将难以通过即席查询进行扩展两张桌子之间。因此，每个层次结构一个表的模型可能更好 - 对象继承被扁平化为单个物理表。

我确实想知道在您的示例中处理重新分类产品的最佳方法是什么。之前创建的任何子类型记录都需要删除，因为每个超类型记录只应存在一个子类型 - 假设只有单层继承。这应该是数据库触发器还是在业务逻辑层中处理的东西？