国际象棋中的数据库设计和规范化答案

【问题标题】：Database Design and normalization in chess国际象棋中的数据库设计和规范化
【发布时间】：2015-02-09 07:09:00
【问题描述】：

我想知道我的数据库/表设计的更好方法是什么。如图所示，我有玩比赛的球员。一名球员打多场比赛，一场比赛由多名球员打，所以它是 n:m 关系。这可能导致 thress 表 player(id, firstname), player_to_match(playerid, matchid), match(id)。在我的例子中，玩家的数量永远不会改变，它总是两个（n = 2）。以下哪个设计更好？

(1)

player_to_match(matchid, playerid)

每张地图有两行和一个单元格冗余（matchid）

(2)

match(matchid, playerid1, playerid2)

正如我所说，每场比赛的球员人数永远不会改变

谢谢

卢卡斯

[具有两个实体的 ERM 图表：玩家（ID，名字），比赛（ID），n:m 从球员到比赛的关联，标题为“plays”] http://fs1.directupload.net/images/141210/rmeuutpg.png

【问题讨论】：

您认为存在“单元冗余”的想法是错误的。一个值在列或表中多次出现与冗余没有任何关系。见this。

标签： database database-design entity-relationship normalization database-normalization

【解决方案1】：

我会坚持选项 (1)。它将更容易回答诸如“球员 X 参加了多少场比赛？”之类的简单问题。使用选项 (2)，您必须查询两列的值 X 才能回答该问题，这开始变得丑陋。

【讨论】：

有效点。这真的取决于你的总体目标是什么。如果您不需要此类分析，请省去管理中间表的工作。
@PhillipXT 我一直更像是一个“正常化直到它受伤；非正常化直到它起作用”的那种人。现在，我找不到选项 (2) 的非规范化的任何需要或好处。
"玩家 X 打了多少场比赛？"在我的项目中肯定会是一个需要回答的问题

【解决方案2】：

使用 2 表设计。对于这样的事情，您不需要额外的复杂性，因为国际象棋不可能需要 3 个玩家。除非你看生活大爆炸……

我更喜欢从更简单的形式开始，然后在需要时对其进行修改。作为开发人员，我们倾向于尝试提出一个能够处理任何未来可能性的解决方案，但大多数情况下它从未发生过，而且我们浪费了很多时间来为一个不存在的问题构建一个优雅的解决方案.先简单点。

如果您确实需要 3 表选项，则需要做一些额外的工作来确保始终有 2 条相关记录匹配，不多也不少。确保您不能删除附加到现有比赛的用户，否则您将进行一场只有一名玩家的比赛。您必须注意一些类似的事情。

【讨论】：

【解决方案3】：

我会这样做：

matchid
black  (references PLAYER)
white  (references PLAYER)

游戏中的玩家数量是有限的（两个），这消除了 1 对 n 子表的基本原理；此外，每个玩家都有一个明确的“角色”（白色与黑色），您希望能够以这种方式区分它们。

【讨论】：

你为什么要这样做？请通过编辑您的答案来澄清。 (LQRQ)
在我的情况下，我永远不会区分两个玩家，所以两个玩家列中不会有额外的信息
不确定你的意思，@Beginner，你“永远不会区分这两个玩家”。你是说你不想知道在特定游戏中哪个玩家是黑人，哪个是白人？
是的。国际象棋只是一个例子，玩家之间的区别不应成为争论。