Question

我有一个动态数据模型，可能有数千个实体表，我们称之为E1，E2，......，或者通常称为EX。

还有少量的实用程序表，其中包含可能附加到这些实体的数据，例如审计表或“附加文档”表，我们称之为U1，U2，......或一般UX。

每对EX-UX的关系是1对多（例如，E1中的每个实例可能有几个附加文档，但每个文档只附加到任何EX中的一个实例）。

基本问题是每个UX都包含引用不同表EX的行。

有几种方法可以模拟这种关系：

链接表解决方案

为每对EX / UX创建一个链接表。例如：

E1_U1 (
    E1_ID FK TO E1
    U1_ID FK TO U1
)

优点：清洁。没有改变EX的型号
缺点：表的数量爆炸，我们也可以为每个实体创建每个实用程序表的实例。如果我需要反向查找，例如告诉我EX中的实例，它被U1中的某个实例引用，我需要搜索所有链接表EX_U1。

实体表解决方案

创建一个新的表ENTITY，其中包含一列ENTITY_ID，它是任何EX中每行的唯一ID。在这个模型中，用ENTITY_ID替换每个EX的主键是有意义的。

ENTITY (
    ENTITY_ID PK
)

E1 (
    ENTITY_ID PK, FK TO ENTITY
    ...
)

U1 (
    U1_ID PK
    ENTITY_ID FK TO ENTITY
    ...
)

优点：我想这是模型继承的标准方法
缺点：显着改变数据模型和应用程序逻辑。只能通过搜索所有EX以获得正确的ENTITY_ID来进行反向查找。

“键入的外键”解决方案

为每个UX提供两列作为“键入的外键”：ETABLE_ID和ETABLE_ROW_ID。 ETABLE_ID引用该表（即EX），ETABLE_ROW_ID表中的行。

在我的模型中，这是可能的，因为

我已经在应用程序逻辑中保留了我的实体表的元模型，因此ETABLE_ID随时可用
ETABLE_ROW_ID保证与所有E

U1 (
    U1_ID PK
    ETABLE_ID FK TO ETABLE
    ETABLE_ROW_ID 
    ...
)

优点：EX模型没有变化。可以在应用程序逻辑中轻松实现反向查找。
缺点：问题显然是我们无法将外键约束应用于ETABLE_ROW_ID。

虽然它不是干净的关系设计，但我仍然赞成最后的解决方案，因为它具有实际优势。丢失的引用完整性我可以在应用程序逻辑中建模。

此问题的首选解决方案是什么？有经验/建议吗？

Answer 1

类型为

的实体表解决方案

ENTITY (
    ENTITY_ID PK,
    ENTITY_TYPE,
    UNIQUE KEY (ENTITY_ID, ENTITY_TYPE)
)

E1 (
    ENTITY_ID PK, 
    ENTITY_TYPE, constrained to value '1'
    FK (ENTITY_ID, ENTITY_TYPE) TO ENTITY table    
    ...
)

U1 (
    U1_ID PK
    ENTITY_ID FK TO ENTITY
    ...
)

将类型存储在ENTITY表中的优点是您不必搜索所有E表以找出它的类型。

每个E表将其自己的类型约束为固定值，因此E1中的任何行自然只能引用类型为1的ENTITY行。

另见：

我过去对polymorphic-associations标记
我的演讲Practical Object Oriented Models In SQL
我的书SQL Antipatterns: Avoiding the Pitfalls of Database Programming

建模许多表共有的数据

1 个答案: