Структура базы данных. Правильно ли это сделать?

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 позволять вашему приложению делать то, что ему нужно. Вероятно, это будет ... но я все равно не буду называть его «правильным» или «неправильным» способом моделирования ваших данных. Тем не менее, это жизнеспособный кандидат. Это правда.