0

这是我对stackoverflow的第一个问题，所以如果我做错了什么，请告诉我我会尽快修复它。

所以我正在尝试为电视节目制作一个数据库，我想知道最好的方法并使我当前的数据库更简单（规范化）。

我将能够具有以下结构或类似结构。

    Fringe  
        Season 1 
            Episodes 1 - 10(whatever there are)
        Season 2 
            Episodes 1 - 10(whatever there are)
        ... (so on)

    Burn Notice
        Season 1 
            Episodes 1 - 10(whatever there are)
        Season 2 
            Episodes 1 - 10(whatever there are)
        ... (so on)

    ... (More Tv Shows)

抱歉，如果这似乎不清楚。（请要求澄清）

但我现在拥有的结构是 3 个表（tvshow_list、tvshow_episodes、tvshow_link）

    //tvshow_list//
    TvShow Name | Director | Company_Created | Language | TVDescription | tv_ID

    //tvshow_episodes//
    tv_ID | EpisodeNum | SeasonNum | EpTitle | EpDescription | Showdate | epid

    //tvshow_link//
    epid | ep_link

董事和公司通过 id 链接到另一个包含公司和董事列表的表。

我很确定有一种更简化的方法可以做到这一点。

提前感谢您的帮助，
Krishanthan Lingeswaran

4

2 回答 2

1

规范化的基本概念是您应该只存储您拥有的任何数据项的一份副本。看起来你已经有了一个好的开始。

有两种基本方法可以对您在此处尝试执行的操作进行建模，分别是剧集和节目。在数据库世界中，您可能听说过“一对多”或“多对多”这个术语。两者都是有用的，它只是取决于您的具体情况来知道哪个是正确的使用。在您的情况下，要问自己的一个大问题是，一集是否可以只属于一个节目，还是一集可以同时属于多个节目？我将解释这两种形式，以及为什么您需要知道该问题的答案。

第一种形式只是外键关系。如果您有两个表，“episodes”和“shows”，在 episodes 表中，您将有一个名为“show_id”的列，其中包含一个（并且只有一个！）节目的 ID。你能明白你怎么不可能以这种方式让一集属于一个以上的节目吗？这称为“一对多”关系，即一个节目可以有很多集。

第二种形式是使用关联表，这是您在示例中使用的形式。这种形式将允许您将一集与多个节目相关联，因此称为“多对多”关系。

使用第一种形式有一些好处，但在大多数情况下，这并不是什么大问题。您的查询会更短一些，因为您只需连接 2 个表即可获得剧集->节目，但另一个表只是一个连接。真正归结为弄清楚您是否需要“一对多”或“多对多”类型的关系。

需要多对多关系的示例是，如果您正在为图书馆建模并且必须跟踪谁签出了哪本书。您将有一个图书表、一个用户表，然后是一个“用户图书”表，其中包含一个 id、一个 book_id 和一个 user_id，并且是多对多关系。

希望有帮助！

于 2010-11-26T19:27:33.483 回答
1

我很确定有一种更简化的方法可以做到这一点。

据我所知不是。您的架构接近于您可以为我认为是您所要求的功能所做的最简单的架构。对它的“改进”实际上只会使它变得更加复杂，并且应该在您判断需要出现在您身边时添加。下面的例子浮现在脑海中（没有一个能真正简化你的模式）。

  • 我会标准化您的外键和主键名称。一个例子是有列shows.id, episodes.id, episodes.show_id, link.id, link.episode_id。
  • SeasonNum在我看来，将我假设的内容放在intEpisodes 表中，违反了规范化约束。这不是重大违规，但如果你真的想坚持下去，我会创建一个单独的 Seasons 表并将其与 Shows 表多对一关联，然后让 Episodes 仅与 Seasons 关联。例如，这使您有机会将信息附加到每个季节。此外，它还可以防止信息重复（虽然 Episodes 表中的季节 ID 外键列的类型表面上仍然是 INT，但外键在哲学上存储了一个关联，即您想要的内容，而不是愚蠢的数据，您拥有的内容）。
  • 您可以考虑将语言、导演和公司放在他们自己的表格中，而不是您的电视节目列表中。这与上述问题相同，在您的情况下是轻微违反规范化。
  • 语言、董事和公司都对协会的水平有兴趣。大多数电视节目的不同剧集都有不同的导演。许多是用多种语言和几个不同的公司，有时是网络制作的。那么您打算在什么级别存储这些信息？我不是软件架构师，所以其他人可以比我更好地回答这个问题，但我会为语言、董事和公司建立一个多态多对多关联，以及一个允许这些值的继承模型逐集、逐季或逐剧指定，如果未提供值，则从其父级继承该值。

关于所有这些建议的底线：选择适合您项目的内容。如果您不需要此级别关联提供的功能，并且您不介意手动输入重复数据（您最终可能会实施一个自动完成系统来帮助您），您可以忽略一些规范化约束。

标准化只是一个建议。选择适合您的方法并从错误中吸取教训。

于 2010-11-26T19:47:33.540 回答