如何为电视跟踪构建表格？答案

【问题标题】：How to structure tables for television tracking?如何为电视跟踪构建表格？
【发布时间】：2020-08-19 08:42:55
【问题描述】：

我正在开发一款应用程序，该应用程序可以跟踪您正在观看的电视节目以及您观看过该节目的哪些剧集。

目前我可以跟踪哪些用户正在观看哪些节目，这比较简单，结构如下：

所以我有一个User 表，其中有一个主键id，用于标识该用户以及有关该用户的其他一些不相关的信息。

在此之后，我有另一个表TV_SHOWS，其中存储了一个user_id 作为外键，其中包含有关节目的一些信息，最重要的是一个名为user_watching 的字段，它给出了一个关于用户是否正在观看该节目的布尔值。

它的工作原理是这样的，当用户单击按钮添加显示时，一行将插入到 TV_SHOWS 表中，其中包含所有信息和 user_watching = true 在某些时候用户可能希望停止观看，以便他们可以单击另一个按钮来简单地更新user_watching = false。

现在我希望扩展这个想法，以便用户可以跟踪他们观看过的电视节目的哪些季节和剧集，一个电视节目由多个季节组成，并且在大多数情况下每个季节都由多个剧集组成。

我想要一些关于如何最好地构建这个数据库模式的帮助。

我最初认为我可以按照以前的方式进行扩展，例如：

我只需为季节和剧集添加两个 ID，这样我就可以通过查看用户是否观看了该季节的所有剧集来判断用户是否观看了该季节，以及通过检查他们是否观看了节目来判断他们是否观看已经观看了该节目的所有季节，但我认为这似乎不是一个好习惯。

我可以尝试为节目制作一张桌子，为每季制作一张桌子，为剧集制作一张决赛桌，但我不确定我会在哪里“追踪”用户是否看过其中的一张，它是否必须在那个特定的表还是我需要另一个表来跟踪它？

【问题讨论】：

标签： sql database design-patterns database-design database-schema

【解决方案1】：

简短回答：从可扩展设计的角度来看，我认为后一种设计是更好的选择。

更长的答案：

将节目季剧集分成单独的表格的后一种选项更接近教科书的设计。 Third Normal Form，我想。这个想法是您希望尽可能减少冗余数据，以最小化存储空间。最小化冗余数据是一般的最佳实践。通过将这三者分开，您可以防止特定于每个主题的属性被复制。

例如，假设您跟踪电视节目的属性，如标题、描述或平均排名。如果您维护一个包含节目/季节/剧集的表，那么在技术上应该为每个季节和每个剧集复制电视节目属性（即冗余），以维护表约束。相反，将电视节目属性分离出来，避免了冗余的属性数据。它还有助于允许属性集随时间增长/更改。

这种设计实践虽然会带来计算成本，因为您需要根据用例将结构连接在一起。例如，如果您总是需要知道节目标题、第 X 季和剧集标题（来自每个表的属性），那么您需要开发必要的连接逻辑来获取这些属性。可以使用 View 来降低成本，这会开启另一组决策。

您对需要两个键的评论。按照三表设计，您可能需要在每个表上都有某种主键。如果您使用季节（可能还有节目）的引用键来构建情节表，那么您应该只需要使用情节键，因为您可以使用连接逻辑从情节中取消引用季节和电视节目。实际上，这一集应该足以从链接中找出季节和电视节目。

【讨论】：

【解决方案2】：

-- User USR exists.
--
user {USR}
  PK {USR}

-- TV show SHW exists.
--
show {SHW}
  PK {SHW}

-- Season number SEA# of show SHW exists.
--
season {SHW, SEA#}
    PK {SHW, SEA#}

    FK {SHW} REFERENCES show {SHW}

-- Episode number EPI# of season number SEA#
-- of show SHW, in duration of DUR_E minutes, exists.
--
episode {SHW, SEA#, EPI#, DUR_E}
     PK {SHW, SEA#, EPI#}

     FK {SHW, SEA#} REFERENCES season {SHW, SEA#}

-- User USR watched DUR_W minutes of episode number EPI#
-- of season number SEA# of show SHW.
--
user_show {USR, SHW, SEA#, EPI#, DUR_W}
       PK {USR, SHW, SEA#, EPI#}

    FK1 {SHW, SEA#, EPI#} REFERENCES
episode {SHW, SEA#, EPI#}

    FK2 {USR} REFERENCES user {USR}

注意：

All attributes (columns) NOT NULL

PK = Primary Key
FK = Foreign Key

Using suffix # to save on screen space.
OK for SQL Server and Oracle, for others use _NO.
For example, rename EPI# to EPI_NO.

【讨论】：