主页 / dba / 问题 / 58308
Accepted
starlocke
Asked: 2014-02-06 12:00:53 +0800 CST

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

  • 772

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

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”之类的值。这是某种“穷人的参照完整性”。显然，这种设计的失败之一是能够插入无法解析为有用连接的值（即：这里没有樱桃可言）。

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

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

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

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

database-design design-pattern

2 个回答

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

    您缺少一个通用Fruit表（即"supertype"）和一个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)

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

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

    • 5
  2. Best Answer

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

    确实，这在 DBA 世界中是一件不可忽视的“事情”，而且，恕我直言，这也是一件令人讨厌甚至被地狱之火烧毁的事情。

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

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

    • 4

相关问题