我该如何建模这个关系？

Question

我的数据库设计技能有点生疏，所以我希望能从你们那里得到一些帮助 =)

我有一个包含所有典型字段（id、name、email等）的“用户”表。用户可以有许多“邀请”。（多对一）每个“邀请”都有一个单一的所有者（用户）。然而，单个“邀请”可以有许多“被邀请人”。

我的困惑是：如果用户可以有许多邀请，并且邀请只能有一个所有者（用户），但是单个邀请可以包含许多被邀请人（这些是用户），应该如何建模？我需要一个新表吗？（“邀请”）

我希望我的问题说得清楚。

- Nick

Answer 1

如果一封邀请只是一封邀请，那么最简单的方式似乎是将所有用户的邀请存储在独立的表中，每个用户占用一行。

Users
 - UserID, PK
 - other details about the users

Invitations
 - InvitationID, PK
 - OwnerID or OwningUserID or just UserID, FK to Users
 - other details about the invitations

InvitationUsers
 - InvitationID, FK to Invitations
 - UserID FK to Users
   [PK on (InvitationID, UserID)]

很多人都会被诱惑将邀请的所有用户存储在逗号分隔的列表或XML中。抵制这种诱惑，它只会带来麻烦。 如果只有一种类型的邀请（比如“成为我的Facebook好友，我们可以拥抱之类的”），那么一个更简单的模型可能是：

Users
 - UserID, PK
 - other details about the users

Invites
 - SenderID, FK to Users(UserID)
 - RecipientID, FK to Users(UserID)
   [PK on (SenderID, RecipientID)]

如果一个所有者可以发送邀请参加各种活动（如约会服务、船展和电影），那么我们需要更多关于这些相关活动的详细信息。

- Aaron Bertrand

---

我正在邀请用户加入一个“列表”。其中，列表是另一个表格。用户可以被分配到多个列表中。在InvitationUsers表中是否包含一个指向列表的外键会不会明智呢？ - Nick

清单和邀请有什么关系吗？ - Aaron Bertrand

是的，邀请是一个加入列表的邀请。 - Nick

那么，ListID难道不只是一个邀请的属性（“关于邀请的其他细节”），并且有一个对Lists的外键吗？为什么需要针对每个用户反复重复ListID呢？ - Aaron Bertrand

你说得对。那实际上就是我所拥有的。我正在用代码创建一个数据模型。我试图使用一个叫做Doctrine的ORM来定义实体关系。感觉就像在玩杂耍一样 :) 非常感谢你的帮助。 - Nick

Answer 2

你的方向是正确的，但我会使用不同的术语。邀请是请求参加某种活动的行为，因此更合适的命名应该是： 活动（活动编号，所有者用户编号） 邀请（活动编号，用户编号）

- Mark Storey-Smith