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

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

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

至于“这是为这个特定目的构建数据库的正确方法吗？”，这实际上是一个模糊而棘手的问题。这个数据模型会起作用吗？是。它是“正确的方式”来建模吗？不是的。因为根本就没有“正确的方法”。这完全取决于你需要什么。如果您的表中充满了兆字节的数据和低延迟/高可用性的需求，那么您可能希望尽可能地去修饰这个表，甚至考虑使用NoSQL解决方案，如Cassandra、Mongo或CouchDB (或其他任何一种)。或者，如果您正在执行大量的插入，并且具有极低的延迟要求，那么您可能希望完全摆脱外键。如果您对MySQL分片感到满意，您可能需要考虑这一点。

没有一个真正的“正确的方法”来建模。但你的肯定是一个可行的候选人。接下来需要考虑的是应用程序本身，以及规范化的SQL数据库是否允许应用程序完成它需要做的事情。很可能会..。但我仍然不愿称它为“正确”或“不正确”的数据建模方式。不过，这是一个可行的候选人。这么多都是真的。