一对多数据库关系答案

【问题标题】：One to Many Database Relationship一对多数据库关系
【发布时间】：2011-07-30 23:52:14
【问题描述】：

如果有人能帮我解决这个问题，我将不胜感激。我有一个架构，其中包含 4 个与此问题 Books、Groups、ReadingList、Comments 相关的表。系统的用户可以加入一个组并将书籍添加到该组的阅读列表中。一个小组的书单由表 ReadingList 表示：

ReadingList
-------------
Id (auto_increment)
ReadingListID
BookID (pk)
GroupID (pk)

BookID 和 GroupID 被设置为复合主键，以确保没有书籍可以出现在组阅读列表中两次。这两个字段都有一个定义到相关表 Books/Groups 的 fk。现在我的问题是在尝试在 Comments 表和 ReadingList 之间建立关系时出现。理论上，ReadingList 中的每个唯一条目都可以有许多 cmets (1..*)，因此基本上组阅读列表中的一本书可以有许多与 in 相关联的 cmets。Comments 表如下所示：

Comments
-----------
Id (pk, auto_increment)
ReadingListID
UserName
Comment
TimeStamp

我的逻辑是从 Comments (ReadingListID) 到 ReadingList (ReadingListID) 设置一个 fk，但我显然有缺陷，因为我收到“引用表中没有主键或候选键”错误。

我尝试了很多方法，例如将 Comments 表中的 ReadingListID 和 Id 设为复合键，并将 ReadingListID 设为 ReadingList 表中的 pk 等，但我无法理解这一点。如果我还不够清楚，请告诉我。

非常感谢！

【问题讨论】：

如何创建 ReadingList-> ReadingListID 是唯一的吗？

标签： database database-design normalization

【解决方案1】：

BookInGroupCommentNo 是 integer，每个 GroupID, BookID 组合的序列号 (1,2,3..)。使用

创建新评论时可以轻松获取

select
    coalesce(max(BookInGroupCommentNo), 0) + 1  
from ReadingList
where GroupID = some_group_id
  and BookID  = some_book_id ;

从ReadingList 和Comment 表中删除那些自动递增的IDs 和ReadingListID。

【讨论】：

ERD 的 +1 以及标准化水平的提高（即使用自然键而不是人工键）......毕竟它被标记为“标准化”。
这引发了一场有趣的辩论“代理键与复合键”stackoverflow.com/questions/977615/…stackoverflow.com/questions/977615/… => 没有“绝对”答案，取决于您需要什么，但 IMO 最好了解利弊每种方法。
@Frosty Z，是的，这取决于但这是另一个例子stackoverflow.com/questions/4520289/…

【解决方案2】：

您可以做的是使用将 ReadingList 的主键从复合 (BookID+GroupID) 更改为 ReadingListID 列，然后您的 FK 将起作用。然后，您可以跨 BookID+GroupID 列创建唯一约束或索引，以确保数据完整性。

不过，我很困惑，为什么您在 ReadingList (Id) 上有一个自动增量，它与您的 ReadingListID 列是分开的。也许你应该放弃其中一个。在我看来，您的架构似乎是这样设置的，也许 ReadingList.Id 是 PK，而 Comments.ReadingListID 是该列的 FK。

【讨论】：

ReadingList.ReadingListID 似乎是必需的，因为 Comments 表用作 FK。
感谢您的评论，我完全同意您的看法，我需要删除 Id 或 ReadingListID 我现在可以看到。我会试试这个，让你知道我是怎么做的。再次感谢您抽出宝贵时间回复。
@Frosty - 对，但这是一个命名约定。虽然我不这样做，但有些人倾向于将每个表中的 PK 命名为“ID”，指向它的 FK 命名为 ID。我不知道他是怎么做的，我猜测了一下，因为他的 Comments 表的 PK 是 Id 列。
@Dane：我同意，我也不得不猜测 :)

【解决方案3】：

那是因为 ReadingList 的 Primary Key 实际上是一个复合键（BookID、GroupID）。您应该更新您的 Comments 表并使用 BookID 和 GroupID 而不是 ReadingListID。

为什么会有 ReadingListID？您不需要它，因为您已经定义了复合主键。

【讨论】：

【解决方案4】：

我建议：

ReadingList
-------------
ReadingListID (pk, auto_increment)
BookID (fk)
GroupID (fk)
+ Unique index on (BookID, GroupID)

Comments
-----------
CommentID (pk, auto_increment)
ReadingListID
UserName
Comment (maybe "Content", "Value" or "Body" could help avoid typing comments.comment)
TimeStamp

【讨论】：