让玩家匹配的正确标准化答案

【问题标题】：Correct Normalization for Players to Match让玩家匹配的正确标准化
【发布时间】：2015-03-21 06:16:23
【问题描述】：

每场比赛有 14 名玩家。

我目前拥有它，因此我可以像这样在匹配表中输入 14 个条目：

matchID    bookingID    playerID
1          1            1
1          1            2
1          1            3
1          1            4

等等

这样可以吗？还是这样更容易接受：

matchID    bookingID    playerID1    playerID2    playerID3    playerID4
1          1            1            2            3            4

【问题讨论】：

您想从规范化结构切换到最差的结构。就我而言，这没关系，这不是我的代码，但既然你知道规范化，那就坚持下去吧！仅当您确定 1 场比赛将永远有 14 名球员时，您的第二个代码才可以使用。但即便如此，你也不能称之为规范化，只是碰巧起作用的糟糕设计。

【解决方案1】：

不，在这种情况下，“规范化”意味着您需要创建多个表，Match、MatchPlayer、Booking 和 Player，它们根据它们的主键相互关联。例如：

Match表：

MatchID    BookingID
---------------------

PlayerMatch表：

MatchID    PlayerID
-------------------

Booking表：

BookingID
----------

Player表：

PlayerID
--------

现在MatchID是Match表中的主键，它是MatchPlayer表中的外键，PlayerID是Player表中的主键，它是外键在MatchPlayer 表中。这在比赛和球员之间建立了“多对多”的关系，因为一个球员可以参加多场比赛，而且在给定的比赛中显然有多个球员。

另外，BookingID 是Booking 表中的主键，它是Match 表中的外键，在这种情况下，预订和匹配之间存在“一对多”关系，因为每次预订可以有多个匹配项。

例如，这种方法允许您为每个玩家创建一个记录，这样您就可以获得有关玩家的其他信息，而无需在 Match 表中不必要地重复该信息，例如名字、姓氏姓名、年龄、性别等。同样，它允许您拥有一个记录，其中包含有关预订的信息，例如日期、场地名称等。

鉴于您当前的示例，标准化似乎是不必要的，因为您没有关于球员和预订的任何其他信息，但您的架构似乎可以快速扩展以包含更多信息。

【讨论】：

抱歉，我应该确认我拥有的不仅仅是这张桌子。我的表是匹配的 - matchID bookingID playerID 玩家 - 姓名、联系人等预订 - 地点、日期等我已经设置了一个类似于你在这里描述的表我只是不确定什么是最好的输入球员来匹配。保留我当前的匹配表格式是否明智，或者我应该切换它以删除 MM 关系是我要问的......必须记住让我的问题更清楚！
另外，每次预订不能超过一场比赛，那么比赛表是否应该只是bookingID和playerID并废弃matchID？
好吧，现在这是一个不同的问题。关于是否使用所谓的“代理”密钥或使用“复合”密钥一直存在争议。你必须谷歌它并决定什么是最适合你的。对于它的价值，我总是使用代理键来保持一致。
那么在这种情况下，当前系统是跟踪我的球员参加比赛的最佳方式吗？我真的觉得 bookingID 和 matchID 一遍又一遍地重复是不好的规范化，但我不喜欢这些东西。