【问题标题】:The best way to structure this database?构建这个数据库的最佳方式是什么?
【发布时间】:2010-06-17 22:53:29
【问题描述】:

目前我正在这样做:

gems(id, name, colour, level, effects, source)

id 是主键,不是自增的。

典型的数据行如下所示:

id      =>   40153
name    =>   Veiled Ametrine
colour  =>   Orange
level   =>   80
effects =>   +12 sp, +10 hit
source  =>   Ametrine

(你们中的一些玩家可能会看到我在这里做什么:))

但我意识到这可以更好地排序。我在我的 A-Level 计算课程中研究过数据库关系和辅助键,但从来没有达到正确设置的程度。我只需要有关如何组织该数据库的帮助,例如哪些表应该包含哪些数据以及哪些辅助键和外键?

我在想可能有 3 张桌子:gemeffectssource。那么哪些人有关系呢?

任何人都可以对此有所了解吗?像我提议的那样复杂的方式真的是要走的路还是我应该继续我正在做的事情?

干杯。

【问题讨论】:

    标签: mysql database-design foreign-keys primary-key


    【解决方案1】:

    我碰巧对您所描述的环境非常熟悉 (:)) 尽管你已经说服了自己,但你所做的并不是特别复杂。

    无论如何,目前,您有一个没有关系的表。这很简单。这很简单。每个 gem 都存在于数据库中。

    如果您要转移到您提议的三个表,您将需要包含链接表以将表组合成可用数据,特别是因为(请注意,我不太确定你的区别是如何沸腾的)效果和源表涉及多对x关系:每个宝石最多有两个效果,每个效果最多有Y个宝石存在//每个来源最多Z 宝石。

    我会坚持使用单张桌子。单个记录可能会更长,但它要简单得多,而且与尝试建立链接表等相比,您遇到的错误更少。

    【讨论】:

    • 我可能在额外的桌子上太过分了,因为 OP 说每个宝石“可以产生很多效果”。在我看来,“很多”与“两个”有很大的不同,足以保证额外的桌子。
    • 是的。 2 是最大值(假设他说的是魔兽世界,而我的知识并不过时)
    【解决方案2】:

    要问自己的问题:

    1. 宝石、效果和来源之间是否存在一对一的关系?
    2. 您是否经常在不从 gem 中提取数据的情况下提取效果?

    如果建议的表格具有一对一的关系,那么我建议将它们组合在一个表格中。在这种情况下,我唯一会考虑将它们分开的情况是,如果我只需要来自效果的数据而不需要其他数据,并且这些表将足够大以证明将它们存储在不同的驱动器上是合理的。否则,您只是在为自己工作,增加更多的存储需求并获得零收益。

    【讨论】:

    • 目前是这样的:一颗宝石可以产生多种效果。一颗宝石可以有一个来源。这真的值得这样吗?
    • @James P 你没仔细看。一宝一源,一源多宝。那是多对一的关系。同样,一颗宝石有 1 或 2 个效果,但这些效果可以有(即出现在)许多宝石上。在最坏的情况下,这是一个多对多关系,它比多对一增加了更多的关系复杂性。
    【解决方案3】:

    您还应该考虑是否需要effects 信息以供实际使用,还是仅显示。如果它只是显示,那么将它放在表格的一列中没什么大不了的。如果您必须使用它,例如适当地应用 +12 和 +10,那么我认为您应该将它的每次出现放在单独的列中。因此,您应该有一个单独的表用于effects,然后是一个单独的表来存储哪些宝石具有哪些效果,可能是gemeffectsEffects 表可能对“sp”的含义有更好的描述,可能是最小和最大范围等。GemEffects 表只有 gem id、值和效果本身。例如

    效果

    effect  => hit
    desc    => How many hit points
    minimum => 0
    maximum => 100
    

    宝石效果

    id     => 40153
    effect => sp
    value  => 12
    

    id     => 40153
    effect => hit
    value  => 10
    

    【讨论】:

      【解决方案4】:

      如果你做一个简单的练习,你会回答你自己的问题:用一种自然的、描述性的语言描述你的系统。哪些实体、它们的属性、它们如何与其他实体交互等。在实体和动词下划线。询问您要管理哪些实体(例如:是否有管理“效果”表的界面?)您会惊讶于它是如何自然组装的。

      现在对于你的例子,我建议两种方法(没有语法细节)

      1) 获得关系设计方面的经验,具有一些复杂性开销,并且对每个实体进行精细化

      • gem (id, name,color_id,source_id,effect_assoc_id)
      • 颜色(ID、名称)
      • 来源(ID、名称)
      • 效果(id,value,nature_id)
      • 性质(身份证、姓名)
      • effect_assoc (id, gem_id, effect_id)

      2) 直截了当,可能有效,具体取决于您的关系的基数

      继续;)

      根据你的描述,我会选择#1。

      【讨论】:

        【解决方案5】:

        我会推荐以下内容:

        1. 将所有效果移动到它们自己的表中(例如,ID、名称、描述、启用...)
        2. 将源移动到其自己的表中(例如,ID、名称、描述、启用...)
        3. 删除宝石“效果”列(迁移到下面的第 5 步)
        4. 将 gems“源”列转换为与“源”表中的 PK 对应的外键值
        5. 添加新表以将单个 gem 实体链接到零个或多个效果实体
          示例:tbl_GemsEffectsLink,有两列名为“GemID”和“EffectID”,由
          它们本身是返回实体表的外键,当它们放在一起时,构成
          复合主键。

          此链接表的示例视图如下:
                GemID EffectID
                  1      1
                  1      2
                  2      1
                  2      2
                  2      3
          

        因此,总而言之,您将拥有以下表格:

        1. 宝石
        2. 效果
        3. 来源
        4. 宝石效果链接

        每个表都有以下列:

        1. 宝石
          身份证 (PK)
          名称
          颜色
          等级
          sourceid (FK)
               

        2. 效果
          身份证 (PK)
          名称
          说明
          启用
          ...
               

        3. 来源
          身份证 (PK)
          名称
          说明
          启用
          ...
               

        4. 宝石效果链接
          gemid (FK)
          有效 (FK)
               

        最后,这假设每个 gem 可以有零个或多个效果,单个源(您可以为此 gem.sourceid FK 字段强制为 NULL 或 NOT NULL),并且级别整数值就是那个(即,不代表更健壮和详尽的东西,因为存在某种类型的“级别”实体,并且示例数据行中的“80”值唯一标识了这些“级别”实体之一。

        希望这会有所帮助!
        迈克尔

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2013-05-01
          • 2022-01-19
          • 2011-09-03
          • 2010-12-24
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多