加入/链接/多对多表的准则

Question

我有自己的理论来做最好的方法，但我认为它是一个共同的主题，我会对人们使用的不同方法感兴趣。

什么是处理多对多连接表的最佳方式，特别是在命名它们时，当你需要为关系添加额外信息时该怎么做，以及如何处理之间有多种关系两张桌子？

假设您有两个表，即用户和事件，需要存储与会者。因此，您创建EventAttendees表。然后需要存储组织者的要求。你应该

1. 创建一个EventOrganisers表，因此每个新关系都使用连接表建模 或
2. 将EventAttendees重命名为UserEventRelationship（或其他名称，如User2Event或UserEventMap或UserToEvent），以及IsAttending列和IsOrganiser列，即您有一个表存储两个与会者之间的所有关系信息 或
3. 两者兼而有之（真的吗？） 或
4. 其他完全不同的东西？

思想？

Answer 1

像这样的一般性问题的简单答案一如既往，“这完全取决于细节”。

但总的来说，我尝试创建更少的表，这可以在不过度滥用数据定义的情况下完成。因此，在您的示例中，我可能会在表中添加一个isOrganizer列，或者可能是一个与会者类型，以便将来从受众/组织者轻松扩展到受众/组织者/演讲者/餐饮服务商或任何可能需要的内容。创建一个具有基本相同列的额外表，其中表名实际上是一个标识“与会者类型”的标志，在我看来，从原始设计角度和实际角度来看都是错误的方式。

单个表格更灵活。有了一个表和一个类型字段，如果我们只想知道组织者 - 比如当我们发送计划意义的邀请时 - 很好，我们写“从userevent中选择userid，其中eventid =？和attendeetype ='O' ”。如果我们想知道每个人都会在那里 - 就像我们在午餐桌上打印名片一样 - 我们只是不包括参与者类型测试。

但假设我们有两张桌子。然后，如果我们只想要组织者，那么，这很容易，加入组织者表。但是如果我们想要组织者和观众，那么我们必须做一个联合，这使得查询更加复杂并且通常很慢。如果你正在考虑，做一个工会有什么大不了的？，请注意查询可能还有更多。也许一个人可以拥有多个电话号码，我们关心这一点，因此查询不仅仅是加入用户和eventAttendee，还有电话。也许我们想知道他们是否参加过以前的会议，因为我们给“校友”特别优惠，所以我们必须第二次参加eventAttendee等等。与工会的十桌加入会变得非常混乱和令人困惑阅读。