【问题标题】:Mini-world as table in a relational database?迷你世界作为关系数据库中的表?
【发布时间】:2017-03-21 04:02:53
【问题描述】:

在关系数据库中,例如,如果我们要为足球锦标赛创建数据库,我们将锦标赛视为迷你世界(我们要为其创建数据库并收集数据)。因此,我们可能会创建比赛、团队等表格。而且,我们没有创建一个名为 tournament 的表格,因为我们只有 THE TOURNAMENT,我们正在为此做这一切。

在实践中,我曾经这样做过。但是,如果我想在我的数据库中保存一些关于锦标赛的属性,例如它的名称、日期和举办国……我该怎么办?创建一个只有一条记录的表锦标赛是一种好习惯吗?如果是,那么外键呢?在这种情况下,将锦标赛的 ID 作为外键添加到表比赛、球队......是否很好?如果没有,最佳做法是什么?

为什么要将锦标赛信息存储在数据库中?因为我想创建一个只读取动态数据的网页。我不想将这些信息(比赛名称、日期...)作为静态数据添加到网页上。

我也在考虑产品未来发展的可能性所带来的好处。稍后,我可能有多个锦标赛,并且数据库中的锦标赛表部分将允许在不修改元数据的情况下顺利集成更多锦标赛。

【问题讨论】:

    标签: mysql database database-design relational-database


    【解决方案1】:

    是的,通常使用一行来存储相关的单个值。 (通常这是为参数设置完成的)。但是在您有多个锦标赛之前,您不需要在这一行中为锦标赛提供 id 或在其他表中使用它的外键。

    是的,这有助于扩展到多个锦标赛。它还有助于扩展到数据库的“时间”/历史版本,在该版本中,我们为每一行添加时间戳,以便我们可以查询给定时间的当前状态。 (这通常涉及进一步规范化,以便为一起更改但可能与其他列集在不同时间发生变化的列创建单独的表。)

    在迁移到多个锦标赛时,与任何架构更改一样,将旧表的名称重新定义为新表的视图会很有帮助。不幸的是,SQL DBMS 通常不支持通过视图进行的更新,因此在这方面,从一开始就具有多锦标赛功能的设计可能很有用。

    【讨论】:

    • IMO 你应该假设会发生超过 1 场比赛。与之后更改所有内容相比,现在添加 ID 的工作量很小。也许这段代码可以在其他地方重用。
    猜你喜欢
    • 2012-03-21
    • 2010-09-13
    • 2011-01-15
    • 2021-11-19
    • 2019-03-03
    • 2011-09-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多