【问题标题】：Database design for multiple game variations多种游戏变体的数据库设计
【发布时间】：2011-09-06 18:21:42
【问题描述】：

希望这些表格的目的是显而易见的，但以防万一，这里有一个简单的解释：我基本上希望存储比赛的结果（8 球池等），但也逐帧记录结果。我遇到的问题是，随着应用程序的增长，我打算允许不同的游戏类型，因此，每帧中使用的评分系统会有所不同。我认为下面的解决方案可以工作，但对我来说似乎不太正确，感谢所有建议。

有没有比使用下表更明智的方法：

# 玩家

身份证
姓名
昵称

# NormalMatches

身份证
玩家A
玩家B

# 正常帧数

身份证
match_id
playerAWon (BOOL)

# ScoringPoolMatches

身份证
玩家A
玩家B

# ScoringPoolFrames

身份证
match_id
playerA_cue_ball_potted
playerB_cue_ball_potted
playerA_balls_potted
playerB_balls_potted
playerA_balls_remaining
playerB_balls_remaining

（编辑：修改 ScoringPoolFrame 表以更好地了解问题所在。）

非常感谢。

【问题讨论】：

你是对的。确实缺少一些东西。至少没有机制来记录分数的来源（什么变体）和/或以其他方式区分它。我怀疑缺少某种形式的“游戏”实体。
我会根据帧结果计算匹配结果。在正常比赛中，只有帧的获胜者很重要，所以我会循环查看谁赢得的最多（我在这里使用布尔值来节省空间 - 如果 playerA 获胜，则为 true，否则为 false）。问题是对于一场得分比赛，每个球员可能有不同的分数。即玩家 A 可能在一帧中获得 10 分，而玩家 B 可能获得 20 分。我必须如何计算比赛的获胜者有一个明显的不同。
想想模型和模型存储的东西——就是这样:) 例如，考虑这些问题：数据是如何放入的？模型是否准确地代表了输入的数据？模型中的数据是否包含以后查询所需的所有信息？模型是否包含可以删除的派生信息？（例如，模型是否正常化？）
@pst 在这种情况下，像我所做的那样将每个实体分开不是更好吗？我展示的方法本质上允许添加未来的变化。我只是认为查询可能会变得非常大（因为试图获取玩家玩过的所有游戏需要查询多个表）。另一方面，如果我只查询一个游戏类型，那么如果将数据分成不同的匹配类型，查询肯定会更快吗？

标签： mysql sqlite database-design relational-database entity-relationship

【解决方案1】：

我不确定您的正常比赛表和得分池比赛之间有什么不同...... 我会设置一些不同的东西，一张桌子为一场比赛计分最终的输赢结果，一张桌子为所有比赛/帧计分。（*表示主键字段）

玩家

身份证*
姓名
昵称

匹配

身份证*
玩家A
玩家B
winning_player_id

游戏

match_id *
game_id *
player_id
得分

game_id 可以是保龄球的帧数，或者是网球的固定号码，或者是棒球的一局

您甚至可能希望将匹配表展平为如下所示：

匹配

match_id *
player_id *
获胜者（布尔）

这样您就可以选择某个玩家的所有匹配项，而无需搜索两列。你也可以在一个游戏中拥有两个以上的玩家。

【讨论】：

很抱歉，我可能没有尽可能清楚。计分游戏和普通游戏的区别在于，在普通游戏中可以有赢家和输家，仅此而已。在计分游戏中，两个玩家都有一个需要记录的得分值，以便在游戏结束时将这些值相加得出结果。不过，这些是基本示例，可能会在以后添加更复杂的示例，例如高尔夫球池（见上文）。
好的。我认为我的建议仍然适合您的需求。对于“普通游戏”，您只会在 Matches 表（任一版本）中有一个条目，而在 games 表中没有条目。就像我提到的，任何一场比赛——整个比赛——都可以分解为比赛——时期、四分之一、框架等。命名法可以改变，但原则是一样的。您可以将另一列添加到引用另一个“scoreType”表的游戏表中，以向分数行添加详细信息。 “CueBallsPotted”、“BallsPotted”、“BallsRemaining”都可以是“scoreType”表中的条目

【解决方案2】：

指导原则：少即是多。在这种情况下，更少的表 = 好。

一个匹配就是一个匹配，一个框架就是一个框架，所以...

将“NormalMatches”和“ScoringPoolMatches”表合并在一起，并引入一个列is_scoring boolean 来区分
将“NormalFrames”和“ScoringPoolFrames”表合并为简单的“Frames”（id、playerA_score、playerB_score），但对于普通游戏，只需分配“1”分表示胜利，“0”表示失败。那么你对所有帧的输赢计算都是相同的。

创建视图以捕获计算逻辑，例如

CREATE VIEW FRAME_RESULT AS
SELECT
    id,
    playerA_score > playerB_score as playerAWon,
    playerB_score > playerA_score as playerBWon,
    playerA_score = playerB_score as is_draw
FROM Frames

【讨论】：

谢谢，这听起来很有希望。但是，如果我为高尔夫球池添加功能怎么办？每个框架（洞）都有一个面值和一个设置？我为我的示例提供了两个示例，但随着它的发展，可能会有两个以上的游戏变体，目前无法预测这些变体是什么，因此它必须尽可能灵活。