数据库结构 - 这是一种正确的做事方式吗？

Question

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

     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

如果一个产品可以与多个 production_type 相关联（例如，production_id = 10 具有 type_id = 4 和 type_id = 3），那么是的，您的结构很好。如果生产只能与一种生产类型相关联，那么您不妨将 type_id 放在生产表本身中并避免连接。

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

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