2

我有一个显示表演者和场地列表的应用程序。该应用程序的用户可以选择“收藏”任意数量的每种类型。我想知道是否有一种标准方法可以在 MySQL 数据库中实现这一点。这是我的选择：

  1. 有一张桌子Favorite，存放UserID, Type, TypeID
    • Type将是“表演者”或“场地”
  2. 有一张桌子Favorite，存放UserID, PerformerID, VenueID
    • 对于每个条目，只有一个PerformerIDorVenueID将被允许具有一个值
  3. 有两张桌子Favorite_Performer和Favorite_Venue，每张存放UserID, PerformerID或UserID, VenueID
    • 我认为这将是“关系”的最佳方式。

每种方法的优缺点是什么，就未来的可维护性而言，您会推荐哪种方法？谢谢。

4

1 回答 1

3

选项 3 是最干净的。它使添加和删除收藏夹变得最简单。这是 ORM 框架将实现的模式。

选项 1 是可行的，但您无法定义外键约束来强制完整性。在查询中添加谓词WHERE type='Venue'，使得使用该表几乎就像使用单独的“Favorite_Venue”表一样。

如果收藏夹已经存在，选项 2 会使添加收藏夹复杂化。（这需要更新现有行，而不是插入。如果有人有两个最喜欢的场地和五个最喜欢的表演者，那会有多少行？但至少可以定义外键。

假设我们有两个最喜欢的场地和两个最喜欢的表演者：

userID  venueID  performerID
------  ------- -----------
     1       11          177
     1     NULL          654
     1       12         NULL

当最喜欢的场地 ID 11 被删除时，您将更新该行以将场地 ID 设置为 NULL。但是如果将venueID 12 作为收藏项删除，您是将该列设置为NULL，还是删除该行。当您要添加最喜欢的表演者时，您是更新现有的 performerID 为 NULL 的行，还是插入一行。不是不可行，但它更复杂。

如果我们有一条规则说只能填充其中一个列venueID 或performerID，那么使用谓词likeWHERE venueID IS NOT NULL将使处理这个表几乎就像处理一个单独的Favorite_Venue 表一样。

最重要的是，我会选择选项 3，除非有一些令人信服的理由不这样做。

这不是“混乱”。这些表Favorite_Venue 和Favorite_Performer 中的每一个都有一个目的，一个“存在的理由”，一个它存在的原因。每个表解析多对多关系。

将这两个单独的“关系”表组合成一个表实际上会造成混乱。如果我们添加一列来区分行（以有效地回答问题，该行真正属于哪个表），则该列是“混乱”的。如果我们在同一行上为两个关系使用两个单独的列，则会在处理添加或删除收藏夹的代码中产生混乱。

于 2013-07-26T18:40:16.360 回答