【问题标题】:1:1 Relationships. Split into more than 1 table? Bad?1:1 关系。拆分成超过 1 个表?坏的?
【发布时间】:2017-10-03 21:36:38
【问题描述】:

我正在开发一款手机游戏,我乐观地希望我能拥有数百万玩家。

我创建了一个用户表,目前大约有 8 列(即用户 ID、用户名、密码、last_signin 等)

对于每个用户,我还需要记录他们拥有的游戏内货币数量(即金、银、宝石等)。

这是一种 1:1 的关系(用户永远只有 1 个值来定义他们拥有多少黄金)。

我不是数据库专家(这就是我在这里发帖的原因)。我担心如果我在用户表中添加黄金、白银、宝石等作为新行,那么用户表将受到每秒疯狂数量的查询的冲击。每当有人在游戏中发现更多金币、更多银币、登录、创建帐户...用户表就会被访问和/或更新。

将黄金、白银和宝石作为列添加到名为“资源”的新表中是否更聪明,该表具有以下列:用户 ID、黄金、白银、宝石。由于用户和资源之间存在 1:1 的关系,因此该新表将具有与用户表完全相同的行数。我想知道这些查询是否会更快,因为数据库数据被拆分并且并非所有查询都会转到同一个表。

在我看来,显然最好将它们全部放在一张表中,因为它们是 1:1.... 但是将大部分游戏数据放在一张表中似乎也是个坏主意。

感谢您提供的任何建议!

瑞恩

【问题讨论】:

    标签: database postgresql database-design


    【解决方案1】:

    在很多情况下,良好的设计需要两个表以 1:1 的关系相互关联。没有规范化规则要求以这种方式分解表。但规范化并不是优秀设计的唯一方法。

    访问流量是另一个句柄。您认为访问资源将比访问基本用户数据更频繁的直觉听起来是可信的。但是您需要检查一下,以确保访问资源的事务最终不会使用基本用户数据。这一切都归结为哪个成本更高:胖用户表或更多联接。

    其他响应者已经暗示有一天,1:1 的关系可能会变成 1:many 的关系。我可以想象一个。游戏玩家的模型得到扩展,单个用户可以参与游戏的多个不同实例。在这种情况下,单个用户可能在所有实例中具有相同的基本用户数据,但在每个实例中具有不同的资源。我无法判断这是否会发生在你的情况下。但是,如果确实如此,那么使用单独的资源表会更好。

    【讨论】:

      【解决方案2】:

      这实际上取决于您的游戏设计、您的数据库有多大,以及您将来如何扩展您的数据库。我会将资源放在一个单独的表中,外键指向用户 ID,因为:

      1. 您可以使用户表更小更轻松 维护/备份。
      2. 两个之间简单的一对一 JOIN 操作 表并不比把所有东西都放在里面占用更多的资源 同一个表,只要您有正确的索引。
      3. 通过保持表格分离,您正在练习关注点分离; 多人可以处理不同的事情而不必担心 关于影响其他表。
      4. 更容易扩展。您可能想要添加其他列,例如birth_date、region、first_name 等 与用户表中的用户个人信息更相​​关 未来。如果不同目的的列是混淆的 一起存放。 (在 PostgreSQL 中你不能简单地排列列 尽管您可以为此创建视图。)

      【讨论】:

        【解决方案3】:

        这是一种 1:1 的关系(用户永远只有 1 个值来定义他们拥有多少黄金)。

        ...暂时;)

        我不是数据库专家(这就是我在这里发帖的原因)。我担心如果我在用户表中添加金、银、宝石等作为新行

        新列?

        将黄金、白银和宝石作为列添加到名为“资源”的新表中会不会更聪明

        可能是因为:

        • 当您更新频繁更新的部分时,您将进行较小的写入,而无需重写修改较少的用户数据

        • 它使审核用户数据的更改变得更加容易

        【讨论】:

          猜你喜欢
          • 2018-02-18
          • 2014-04-03
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2011-06-12
          • 2013-08-08
          • 2021-11-25
          • 2014-04-19
          相关资源
          最近更新 更多