数据库设计问题（或问题）
我正在设计一个包含三个表的数据库：用户、游戏和（可能）注册。我想表示用户可以注册零个或多个游戏。
我使用表寄存器来注册游戏中的用户。
我还需要存储用户在游戏中的得分。
我的问题是：
我可以在表寄存器中添加一个名为“分数”的列吗？这是一个好的设计吗？
谢谢。
I'm designing a database with three tables: user, game and (probably) register. I want to represent that a user can be registered on zero or more games.
I use table register to register a user in a game.
I also need to store the score of the user in a game.
My question is:
Can I add a column called score in table register? Is it a good design?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
是的，这是一个不错的设计。但您可能应该更改命名。
Yes it is an ok design. But you should probably change the naming.
您所描述的是多对多关系，使用 REGISTER 作为交叉引用表：
听起来不错，但如果游戏相关或注册相关信息变得更复杂，您最终可能会将其分成两部分。
编辑添加：通常您最终会想要保存游戏历史记录（“平均得分”、“最近 5 场比赛”、“最快时间”等）。然后，
REGISTER和GAME_HISTORY表之间就建立了一对多关系。另外，我同意这个答案，即如果它包含非注册信息，则将其称为“注册”表会令人困惑。
What you're describing is a many-to-many relationship, using REGISTER as the cross-reference table:
Sounds okay, though if either game-related or registration-related info gets more complicated you'll probably split it in two eventually.
Edited to add: Often you'll end up wanting to save game history ("average score", "last 5 games", "fastest time", etcetera). Then you have a one-to-many relationship between
REGISTERand aGAME_HISTORYtable.Also, I agree with the answer that said calling it a 'registration' table will be confusing if it contains non-registration info.
您可以将用户 ID 和游戏 ID 以及分数放入注册表中。这将允许您让一个用户注册许多游戏，每个游戏都有一个分数。如果我正确理解你的问题，我认为这可能会达到你想要的效果。
You can put a user id and a game id into the register table, along with with a score. This will allow you to have a user registered for many games, each with a score. I think that will probably do what you want, if I understood your question correctly.
我想，您将使用寄存器表来避免游戏和用户之间的多对多关系。如果您想保留特定游戏中特定用户的分数，我认为这是一个很好的解决方案。
I imagine, that you are going to use register table to avoid many-to-many relation between game and user. If you want to keep score of particular user in particular game, I think that's good solution.
如果它是一个跟踪不同游戏中用户得分的表格：当然，您可以拥有该列。但也许可以称之为“分数”？ （除非您需要其他信息，否则也许您应该使用第四个表）
If it's a table that keep track of user score in different games: sure, you can have that column. But perhaps call it 'score' instead? (Unless you need some other information there, then perhaps you should use a fourth table)
我认为你应该考虑创建一个“关系”表。
UserId和GameId将是主键，并且分别与User和Game表无关。I think you should consider creating a "relationship" table.
UserIdandGameIdwould be the primary key as well as each being foreign to theUserandGametables, respectively.只要每个寄存器最多可以有一个分数，这可能是一种合适的设计。如果寄存器可能没有分数，那么这将对应于
NULL值。如果这可能是表中行的很大一部分，那么另一个保存分数的表可能是合适的。在我制作的一个应用程序中，我遇到了类似的情况，并且因为我想添加“高分表”功能（这需要在分数列上进行
ORDER BY查询），所以我最终得到了相当多的结果我的“寄存器”表上有很多索引（不止一个只是为了这个目的，因为我必须为不同类型的游戏设置不同的索引）。最后，我制作了一个新的分数表，尽管大多数寄存器确实有关联的分数，以便使这些索引的维护不再成为问题。It is probably an appropriate design, as long as each register can have at most one score. If registers might have no scores, then that would correspond to a value of
NULL. If this might be a significant proportion of rows in the table, then another table to hold scores might arguably be appropriate.In an app I made, I had a similar situation, and because I wanted to add "high-score table" functionality (which necessitates
ORDER BYqueries on the score column), I ended up with quite a lot of indexes on my "register" table (more than one just for this purpose, because I had to have different indexes for different types of game). In the end I made a new table for scores, even though most registers do have an associated score, in order to make maintenance of these indexes less of an issue.如果您的数据库的目标是分析，那么您还将考虑这一点：
请记住，除非您在游戏表中包含一行“没有注册游戏”并将其作为默认值，否则您将执行外连接用户游戏表。您可以在第一次注册时删除该“未注册”...如果最后一次注册被删除，则将其添加回来。
这将使您的报告内部联接，并且查找所有未注册的用户变得简单明了。
If the goal of your database is analytics then you'll also consider this:
Keep in mind that you'll be doing an Outer Join unless you include a row in the game table for 'no games registered' and put that as a default in the usergame table. You can delete that "non-registration" with the first registration... and add it back if the last registration is ever deleted.
This will make your reports inner joins and finding all the users without registrations is simple and obvious.