Question

我的数据库中具有以下结构：

Area:
----------------
Id: (PK, bigint)
AreaName: (varchar)

Post:
----------------
Id: (PK, bigint)
AreaId: (FK, bigint)
Title: (varchar)
Text: (varchar)

Comment:
----------------
Id: (PK, bigint)
PostId: (FK, bigint)
Text: (varchar)

由于在很多情况下我都需要按Area查询评论，所以我的问题是-

最好通过我的Post表加入JOIN来进入Area for Comments，还是像这样修改我的Comment表更好：

Comment:
----------------
Id: (PK, bigint)
AreaId: (FK, bigint)
PostId: (FK, bigint)
Text: (varchar)

“级联”外键而不是为了查询而进行联接的最佳实践是什么？我的直觉告诉我这是个坏主意，但我不能否认这会使我的很多查询变得容易。

我应该构造一个这样做的View吗？另外，对于这种“级联”外键概念是否有术语？尽管感觉这将是一个常见问题，但我很难提供有关此方面的信息。

以下问题提出类似的要求： Three level database - foreign keys

答案指出，这是不必要的（同意），但不是为什么（或是否）这是个坏主意。

Answer 1

通过FK层次化多个层次来模拟“包含”或“属于”类型关系是一种非常普遍且完全正确的做法。但是，您不只是添加FK列，还可以在子表上使用复合PK：

Area:
----------------
AreaId: (PK, bigint)
AreaName: (varchar)

Post:
----------------
AreaId: (PK,FK, bigint)
PostId: (PK, bigint)
Title: (varchar)
Text: (varchar)

Comment:
----------------
AreaId: (PK,FK, bigint)
PostId: (PK,FK, bigint)
CommentId: (PK, bigint)
Text: (varchar)

每个表都有一个FK，而不是两个。所以Comment有一个两列的FK引用Post。

对此模型的唯一真正的抱怨是，您必须在多个列上联接，但这只是在抱怨必须输入。这是最有效的模型，因为相关行一起存储在PK索引中，并且PK索引支持关系的有效查找和遍历。在单列键模型中，必须具有支持FK的辅助索引。

Answer 2

不需要修改。通常，人们使用多个外键来创建简单的查询，对我而言，这绝对不是一个坏主意。

多级数据库外键

2 个答案: