规范化导致查询过多？
Normalization leads to too much queries?
设计 1：
database design 1 image
更多 tables。更好的规范化。数据 clean/better 组合在一起。
问题1：如果用户注册一个账号，是不是查询太多了？
插入播放器 ()...
插入 player_device ()...
插入 player_gameprofiledata ()...
插入 player_personaldata ()...
那是 4 个查询。
更新用户信息可能会再次导致相同数量的查询。
问题 2：将 tableplayer_personaldata 合并到播放器中（如设计 2）是不是一个坏主意？
问题3：玩家与player_device的关系，是1:n还是m:n？
设计 2：
database design 2 image
少 tables，但混合数据。
差异：
- player_device 和 player_personaldata 字段在播放器中 table
- field playername 在 table player 而不是 table player_gameprofiledata（简化登录）
- 无法通过 table player_devic
跟踪当前正在使用的设备
问题 4：即使没有出现大量数据冗余，规范化是否充分还是设计不当？
您的两个设计都同样标准化。
我通常会避免1:1关系。在你的情况下，它甚至会有点危险，因为 DBMS 发现很难保证玩家和 player_gameprofiledata 之间的真实 1:1 关系。很容易保证 1:{0,1} 关系，即一个玩家不超过一个 player_gameprofiledata。这将通过一个简单的外键来完成。但是为了保证每个玩家都存在一个 player_gameprofiledata，反之亦然，必须有一个从 table A 到 table B 并返回的外键，这只能通过 deferred 来完成并非每个 DBMS 都提供的约束。
因此请保持您的数据库简单。一个玩家是一个有玩家名字的玩家，如果数据库只是一个游戏，那么这个玩家也有一个游戏设置等等。一个 table.
（也有例外，例如对 table 的不同访问权限或使用它们的不同程序员。所以在我看来：在真正需要时使用 1:1 table一些原因，否则请避免使用它们。）
问题 1 的答案：别担心。仅在玩家首次注册时才会发生的四次插入并不多。并且更新通常不会影响多个 table。但是，在您的第一个设计中，您拥有的 table 多于所需的数量。您可以（并且我认为应该）保持简单。
问题 2 的答案： 否。合并 1:1 相关的 table 实际上是个好主意。
问题 3 的答案： 一个玩家 has/had 多台设备。一台设备属于一个玩家。所以它是 1:n。如果您有设备 table 而 player_device 将 link 播放器和设备，它将是 m:n。该设计可以帮助避免可能出现的错误，其中一名玩家拥有 android 版本 4.4.1 而另一名玩家拥有 4.4.01。所以我建议添加一个设备table。或者，设备是否更重要。还是单纯的信息？您的 table 表明您对所有这些设备都非常感兴趣。如果是这样，那就彻底去做。如果没有，那么您只需将当前设备属性再次添加到播放器 table 就可以了，就像您在第二种方法中所做的那样。 （你可以添加一个 player_device_history table，每次玩家设备改变时你都会填充它，所以你有历史记录以备不时之需，但是 table 更像是一个记录 table 而不是日常使用中需要的实际 table。）
问题 4 的答案： 两种设计都已规范化并且很好。我会选择第二种设计。但是，如果您将来可能想将此数据库用于多个游戏，那么您应该已经考虑到这一点。
设计 1：
database design 1 image 更多 tables。更好的规范化。数据 clean/better 组合在一起。
问题1：如果用户注册一个账号，是不是查询太多了？
插入播放器 ()...
插入 player_device ()...
插入 player_gameprofiledata ()...
插入 player_personaldata ()...
那是 4 个查询。 更新用户信息可能会再次导致相同数量的查询。
问题 2：将 tableplayer_personaldata 合并到播放器中（如设计 2）是不是一个坏主意？
问题3：玩家与player_device的关系，是1:n还是m:n？
设计 2：
database design 2 image 少 tables，但混合数据。
差异：
- player_device 和 player_personaldata 字段在播放器中 table
- field playername 在 table player 而不是 table player_gameprofiledata（简化登录）
- 无法通过 table player_devic 跟踪当前正在使用的设备
问题 4：即使没有出现大量数据冗余，规范化是否充分还是设计不当？
您的两个设计都同样标准化。
我通常会避免1:1关系。在你的情况下，它甚至会有点危险，因为 DBMS 发现很难保证玩家和 player_gameprofiledata 之间的真实 1:1 关系。很容易保证 1:{0,1} 关系，即一个玩家不超过一个 player_gameprofiledata。这将通过一个简单的外键来完成。但是为了保证每个玩家都存在一个 player_gameprofiledata，反之亦然，必须有一个从 table A 到 table B 并返回的外键，这只能通过 deferred 来完成并非每个 DBMS 都提供的约束。
因此请保持您的数据库简单。一个玩家是一个有玩家名字的玩家，如果数据库只是一个游戏，那么这个玩家也有一个游戏设置等等。一个 table.
（也有例外，例如对 table 的不同访问权限或使用它们的不同程序员。所以在我看来：在真正需要时使用 1:1 table一些原因，否则请避免使用它们。）
问题 1 的答案：别担心。仅在玩家首次注册时才会发生的四次插入并不多。并且更新通常不会影响多个 table。但是，在您的第一个设计中，您拥有的 table 多于所需的数量。您可以（并且我认为应该）保持简单。
问题 2 的答案： 否。合并 1:1 相关的 table 实际上是个好主意。
问题 3 的答案： 一个玩家 has/had 多台设备。一台设备属于一个玩家。所以它是 1:n。如果您有设备 table 而 player_device 将 link 播放器和设备，它将是 m:n。该设计可以帮助避免可能出现的错误，其中一名玩家拥有 android 版本 4.4.1 而另一名玩家拥有 4.4.01。所以我建议添加一个设备table。或者，设备是否更重要。还是单纯的信息？您的 table 表明您对所有这些设备都非常感兴趣。如果是这样，那就彻底去做。如果没有，那么您只需将当前设备属性再次添加到播放器 table 就可以了，就像您在第二种方法中所做的那样。 （你可以添加一个 player_device_history table，每次玩家设备改变时你都会填充它，所以你有历史记录以备不时之需，但是 table 更像是一个记录 table 而不是日常使用中需要的实际 table。）
问题 4 的答案： 两种设计都已规范化并且很好。我会选择第二种设计。但是，如果您将来可能想将此数据库用于多个游戏，那么您应该已经考虑到这一点。