database design 1 image 更多表格。更好的标准化。数据干净/更好地分组在一起。
问题1 ：如果用户正在注册帐户，这是否会进行过多查询？
插入播放器（）...
将INERT插入player_device（）...
INSERT INTO player_gameprofiledata（）...
将INERT插入player_personaldata（）...
这是4个查询。 更新用户信息可能会再次导致相同数量的查询。
问题2 ：将表player_personaldata合并到player中（例如在设计2中）是一个坏主意吗？
问题3 ：播放器和播放器设备之间的关系是1：n还是m：n？
database design 2 image 表较少，但数据混合。
差异：
问题4 ：即使没有严重的数据冗余，规范化还是设计不良？
答案 0 :(得分：0)
您的设计都同样标准化。
我通常避免1：1关系。在您的情况下，这甚至可能有点危险，因为DBMS很难保证玩家和player_gameprofiledata之间真正的1：1关系。保证1：{0,1}关系很容易，即一个玩家最多拥有一个player_gameprofiledata数据。只需一个简单的外键即可完成。但是要确保每个玩家都存在一个player_gameprofiledata，反之亦然，必须从表A到表B再到表B都有一个外键，这只能通过并非每个DBMS都提供的延迟约束来完成。
因此，请保持数据库简单。玩家是具有玩家名称的玩家，如果数据库仅是一个游戏，则该玩家也具有一个游戏设置，例如一张桌子。
（有例外，例如对表的不同访问权限或与它们一起使用的不同程序员。因此，我认为：出于某种原因确实有必要时使用1：1表，否则应避免使用它们。）
问题1的答案：不用担心。仅在玩家首次注册时发生的四个插入次数并不多。而且更新通常不会影响多个表。但是，您的表数量超出了您的第一个设计所需。您可以（而且我认为应该）使其更简单。
问题2的答案：否。合并1：1相关表实际上是个好主意。
问题3：的答案：一位玩家拥有/拥有许多设备。一台设备属于一名玩家。所以是1：n。如果您有一个设备表，而player_device将链接播放器和设备，则它将为m：n。这种设计可以帮助避免一个玩家使用Android 4.4.1和另一个4.4.01版本时可能出现的错误。因此，我建议添加设备表。或者，设备甚至很重要。还是仅仅是信息？您的表格表明您对所有这些设备都非常感兴趣。如果是这种情况，请彻底进行。如果不是这样，那么您只需将当前设备属性再次添加到播放器表中就可以了，就像您在第二种方法中所做的那样。 （您可以添加一个player_device_history表，该表在每次播放器设备发生更改时都会填充，因此您有历史记录，以备不时之需，但是该表更多是日志记录表，而不是您日常使用中需要的实际表）
问题4的答案：两种设计均已标准化且良好。我会选择第二种设计。但是，如果将来您希望将此数据库用于多款游戏，那么您应该已经考虑到这一点。
