这种“穷人的参考完整性”模式设计模式有一个众所周知的名字吗？

Question

以下数据库架构设计/模式是否有名称？我的最终目标是找到更多关于该主题的文献。今天的粗略网络搜索太多通用词，无法确定此类事物的术语（如果存在）：

Fruit (id, farm)

Apple (fruit_id, color)
    [fruit_id => Fruit.id]

Banana (fruit_id, length)
    [fruit_id => Fruit.id]

Orange (fruit_id, is_seedless)
    [fruit_id => Fruit.id]

FruitPack (id, destination)

FruitPackFruits (fruitpack_id, fruit_id, fruit_type)
    [fruit_id => Fruit.id, fruit_type => VARCHAR]

其中fruit_type将是一个varchar 列，其中填充了诸如“Apple、Banana、Orange、Cherry”之类的值。这是某种“穷人的参照完整性”。显然，这种设计的失败之一是能够插入无法解析为有用连接的值（即：这里没有樱桃可言）。

这是此类模式的另一个示例：单个“日志（id、table_name、record_id、timestamp）”表充当各种其他表中修改时间的跟踪器。严格来说，它没有 ref 完整性，但是， (table_name, record_id) 部分应该引用另一个表中的某些记录，需要连接才能实际获取完整数据。

我将理所当然地认为模式是这里人们的某种项目组集合的充分讽刺。

问题是：这种“穷人的参照完整性”叫什么？

我不是想了解参照完整性。我想确定这个糟糕设计的名称，并进一步研究与这种常见的模式灾难有关的“让我们设计一个数据库模式”方面（例如：优点、缺点、意见、教导等）。

Answer 1

您的设计看起来有点像“超类型/子类型”模式。搜索那个和“表继承”。尽管如此，它需要大量的工作才能强制执行完整性约束。

您缺少一个通用Fruit表（即“超类型”）和一个FruitType用于存储允许的水果类型的表：

FruitType 
    fruit_type PK

Fruit
    fruit_type PK, FK -> FruitType (fruit_type)
    fruit_id   PK

然后 3 个（或 4 个或更多）表将是（“子类型”表）：

Apple
    fruit_type 
    fruit_id PK
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)
    CHECK (fruit_type = 'Apple')

Banana 
    fruit_type PK
    fruit_id PK
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)
    CHECK (fruit_type = 'Banana')

Orange
    fruit_type PK
    fruit_id PK
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)
    CHECK (fruit_type = 'Orange')

任何其他表都可以引用该Fruit表：

FruitPack 
    fruitpack_id PK 
    destination

FruitPackFruits 
    fruitpack_id FK -> FruitPack (fruitpack_id)
    fruit_id     
    fruit_type
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)

它看起来不太好，每个“水果”表中的一列似乎是多余的，因为它只有一个允许值。并且每次需要添加新水果（例如 Cherry）时，都必须在表中添加一行FruitType和一个新表 ( Cherry)，与其他表类似。因此，如果您的设计或多或少稳定，效果会更好。如果您发现您可能需要每隔几天添加一个新的“水果”，或者您有一千个（或更多！）不同的水果，这不是最好的方法。

另一方面，它强制执行完整性，您不能将樱桃插入香蕉或橙子插入苹果。

Answer 2

啊哈！感谢@ypercube关于“继承”的评论，我成功地实现了逻辑/上下文的飞跃，并找到了一些具体的例子，为这种模式设计命名为“多态关联”。

• http://www.slideshare.net/billkarwin/practical-object-driven-models-in-sql（幻灯片＃24）

• 在什么条件下使用多态关联？有哪些替代方案？

确实，这是 DBA 世界中不可忽视的“一件事”，而且，恕我直言，这也是令人憎恶甚至被地狱之火焚烧的东西。

在“让我们记录所有内容”的场景中，遵循IBM 的智慧并创建一组一对一的“_history”（附加）表和触发器可能会很好。这似乎也适用于充当“i18n + L10n”翻译存储的表。

除了“从长远来看，多态关联可能是一个坏主意”之外，不知道此时如何看待“让我们对不同类型的项目进行分组”场景。在我基于 MVC 的应用程序的上下文中，跟踪/跟踪/理解/查询它们非常令人不愉快。