数据库设计问题（或问题）

我正在设计一个带有三个表的数据库：用户，游戏和（可能）注册表。我想表示用户可以在零个或多个游戏中注册。数据库设计问题（或问题）

我使用表寄存器在游戏中注册用户。

我还需要在游戏中存储用户的分数。

我的问题是：

我可以在表中添加一个名为score的列吗？这是一个好的设计吗？

谢谢。

来源

2010-10-15 VansFannel

什么你所描述的是一个多一对多的关系，使用寄存器作为交叉引用表：

USER 
UserID 

GAME 
GameID 

REGISTER 
UserID 
GameID 
Score 
[+ registration info]

听起来很不错，但如果无论是游戏相关的或登记相关的信息变得更复杂的你最终可能会把它分成两部分。

编辑补充：通常你最终会想保存游戏历史（“平均分”，“最近5场比赛”，“最快时间”等）。那么你有REGISTER和GAME_HISTORY表之间的一对多关系。

此外，我同意所谓的“注册”表的答案，如果它包含非注册信息将会引起混淆。

来源

2010-10-15 13:44:25 egrunin

感谢您的回答。我在数据库设计方面很新。阅读你的答案我还有一个问题：如果我要添加更多信息，为什么还要拆分表格？我怎样才能将它分成两部分？ – VansFannel 2010-10-15 13:54:51

您可以将用户标识和游戏ID与评分一起放入注册表中。这将允许你有一个用户注册了很多游戏，每个游戏都有一个分数。如果我正确理解你的问题，我认为这可能会做你想做的。

来源

2010-10-15 13:44:01

我想象一下，你要使用注册表来避免游戏和用户之间的多对多关系。如果你想在特定的游戏中保持特定用户的分数，我认为这是一个很好的解决方案。

来源

2010-10-15 13:44:48 mlusiak

是的，这是一个好设计。但你应该改变命名。

user: 
    userid 
    username 

game: 
    gameid 
    name 

usergame: 
    userid 
    gameid 
    score

来源

2010-10-15 13:45:02

这是很好的建议，因为注册（或在这个解决方案中的用户游戏）是为了解决游戏和用户之间的多对多连接。 – mlusiak 2010-10-15 13:46:03

我认为这个命名非常重要。我强烈建议'usergame'（或者，在我看来，更好的是'user_game'）通过'register'。 “注册”这个名称（因为它是一个名词）甚至比“注册”更好。 – 2010-10-15 16:15:46

如果它是跟踪用户评分在不同的游戏表：当然，你可以有柱。但也许称它为'分数'呢？（除非你需要其他一些信息，那么也许你应该使用第四个表）

来源

2010-10-15 13:45:29 erikric

我认为你应该考虑创建一个“关系”表。

UserId | GameId | Score

UserId和GameId将主键以及各自为外源的User和Game表，分别。

来源

2010-10-15 13:46:14 Brad

这可能是一个合适的设计，只要每个注册表最多只能有一个分数。如果寄存器可能没有分数，那么这将对应于值NULL。如果这可能是表格中很大一部分行数，那么另一张保存分数的表格可能是合适的。

在我制作的一个应用程序中，我遇到了类似的情况，并且因为我想添加“高分表”功能（在分数列上需要查询ORDER BY），所以我最终得到了很多索引我的“注册”表（不止一个只是为了这个目的，因为我必须为不同类型的游戏设定不同的索引）。最后，我为分数制作了一张新表，尽管大多数寄存器都有相关的分数，以便使这些索引的维护更少。

来源

2010-10-15 13:49:37 Hammerite

如果你的数据库的目的是分析，那么你还可以这样考虑：

请记住，你会做一个外部联接，除非您在游戏桌上一排“没有注册的游戏'并将其作为usergame表中的默认值。您可以删除第一次注册时的“未注册”...并在最后一次注册被删除时将其添加回去。

这将使您的报告内部联接和查找所有用户没有注册是简单明了的。

来源

2010-10-15 15:53:35

数据库设计问题（或问题）

回答

相关问题