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放在生产表本身中并避免连接。

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

真的不是一种正确的方式＆＃34;模仿这个。但你的当然是一个可行的候选人。您需要考虑的下一件事是您的应用程序本身，以及规范化的SQL数据库是否允许您的应用程序执行它需要执行的操作。它可能会...但我仍然不愿意称它为“正确的”＃34;或＆＃34;不正确＆＃34;模拟数据的方法。虽然这是一个可行的候选人。那是真的。

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

1 个答案: