我想知道我的数据库/表格设计的更好方法是什么。如图所示，我有一些比赛的球员。一个玩家玩多个匹配，一个匹配由多个玩家玩，所以它是n：m关系。这可能导致thress表播放器（id，firstname），player_to_match（playerid，matchid），match（id）。 在我的情况下，玩家的数量永远不会改变，它总是两个（n = 2）。以下哪种设计更好？
（1）
player_to_match（matchid，playerid）
每个地图有两行，一个单元冗余（matchid）
（2）
匹配（matchid，playerid1，playerid2）
正如我所说，每场比赛的球员数量永远不会改变
谢谢
卢卡斯
[有两个实体的ERM图：玩家（ID，名字），匹配（ID），n：m从玩家到比赛的协议标题为＆＃34;播放＆＃34;] http://fs1.directupload.net/images/141210/rmeuutpg.png
答案 0 :(得分：1)
我坚持使用选项（1）。它可以更容易地回答诸如＆＃34;玩家X玩了多少场比赛这样的简单问题？＆＃34;使用选项（2），您必须查询值X的两列才能回答该问题并开始变得难看。
答案 1 :(得分：0)
使用2桌设计。对于这样的事情，你不需要额外的复杂性，因为国际象棋根本不需要3名球员。除非你看大爆炸理论......
我更喜欢从更简单的表单开始，然后在需要时稍后修改它。作为开发人员，我们倾向于尝试提出一种解决方案，以便处理任何未来的可能性，但大部分时间它从未发生过，而且我们浪费了大量时间为一个没有＆＃的问题构建一个优雅的解决方案。 39; t存在。先简单一点。
如果你确实需要3-table选项，你需要做一些额外的工作来确保匹配总是有2条相关记录，不多也不少。确保您无法删除附加到现有匹配的用户，或者您只能与一个玩家匹配。一些你必须要注意的事情。
答案 2 :(得分：0)
我会这样做：
matchid
black (references PLAYER)
white (references PLAYER)
游戏中的玩家数量是有限的（两个），这消除了1对n子表的基本原理;此外，每个玩家都有一个明确的角色＆＃34; （白色与黑色）并且您希望能够以这种方式区分它们。