mysql - 数据库结构 - 这是正确的做事方法吗？

Question

我有一个名为“生产”的表。该表将包含与电影、电视剧、纪录片和动漫相关的数据，这样我就不必为每种类型的制作创建一个表。但这产生了一个问题。由于电视剧也可以是纪录片，因此我必须使用联结表来定义我们正在谈论的制作类型。我将在下面粘贴我的结构。

     Table I : production

     production_id (Auto Increment & Unique)
     production_start_date (Movies won't get any value because start_date is only valid for Tv Series, so some columns will be empty in this table.)
     production_name
     production_end_date (See below)
     production_season_number (see below)

     Table II : types

     type_id (Auto Increment & Unique)
     type_value (This column will store only four values)

     Table III : production_type

     production_id (Foreign Key From production table)
     type_id (Foreign Key from types table)

这是为此特定目的构建数据库的正确方法吗？请具体并尽可能残酷。 :)

Answer 1

如果一个生产可以与多个生产类型相关联(例如，生产id = 10 具有 type_id = 4 和 type_id = 3)，那么是的，您的结构没问题。如果生产只能与一种生产类型关联，那么您不妨将 type_id 放入生产表本身并避免连接。

至于“这是为此特定目的构建数据库的正确方法吗？”，这实际上是一个模糊且棘手的问题。这个数据模型有效吗？是的。这是建模的“正确方法”吗？不。因为首先就没有“正确的方法”。这完全取决于您的需要。如果您有一个巨大的表，其中充满了 TB 级的数据并具有低延迟/高可用性要求，您会希望尽可能地对该表进行非规范化，甚至考虑使用 NoSQL 解决方案，如 Cassandra、Mongo 或 CouchDB(或其中任何一种)好多其它的)。或者，如果您正在进行大量插入并且延迟要求极低，您可能希望完全摆脱外键。如果您对 MySQL 分片感到满意，您可能需要考虑一下。

实际上并没有一个“正确的方法”来对此进行建模。但你的无疑是一个可行的候选人。接下来您需要考虑的是您的应用程序本身，以及规范化的 SQL 数据库是否允许您的应用程序执行其需要执行的操作。它可能会......但我仍然回避称其为“正确”或“不正确”的数据建模方式。不过，它是一个可行的候选者。这是真的。