Метод создания базы данных для ТВ-шоу

Я уверен, что есть более упрощенный способ сделать это.

Не знаю, насколько я знаю. Ваша схема близка к простейшему, что вы можете сделать для того, что я предполагаю, это функциональность, о которой вы просите. "Усовершенствования" на этом действительно только усложняют его, и его следует добавить, поскольку вы судите о том, что на вашей стороне возникает необходимость. Следующие примеры приходят на ум (ни одна из которых действительно упрощает вашу схему).

• Я бы стандартизировал ваши ключи от внешнего ключа и первичного ключа. Примером может служить столбцы shows.id, episodes.id, episodes.show_id, link.id, link.episode_id.
• Полагая SeasonNum, как я полагаю, будет int в таблице Episodes, на мой взгляд, нарушает ограничение нормализации. Это не является серьезным нарушением, но если вы действительно хотите придерживаться этого, я бы создал отдельную таблицу Seasons и связал ее много-к-одному с таблицей Shows, а затем связал Episodes только с Seasons. Это дает вам возможность, например, прикрепить информацию к каждому сезону. Кроме того, это предотвращает повторение информации (в то время как тип столбца внешнего ключа сезона ID в таблице Episodes якобы по-прежнему остается INT, внешний ключ философски сохраняет ассоциацию, что вы хотите, по сравнению с немыми данными, что у вас есть).
• Вы можете подумать о том, чтобы поставить язык, режиссер и компанию в свои собственные таблицы, а не на свой список телешоу. Это те же проблемы, что и выше, и в вашем случае незначительное нарушение нормализации.
• У языка, директора и компании есть интересные вопросы, связанные с уровнем ассоциации. У большинства телешоу есть разные режиссеры для разных эпизодов. Многие из них выпускаются на нескольких языках и несколькими различными компаниями, а иногда и сетями. Итак, на каком уровне вы планируете хранить эту информацию? Я не архитектор программного обеспечения, поэтому кто-то может лучше ответить на этот вопрос, чем я, но я создал полиморфную ассоциацию "многие-ко-многим" для языков, директоров и компаний и модель наследования, которая позволяет этим значениям указывать по эпизоду по эпизоду, по сезону или по отдельности, наследуя значение от своего родителя, если ни один не предоставляется.

Нижняя строка, касающаяся всех этих предложений: Выберите, что подходит для вашего проекта. Если вам не нужна функциональность, предоставляемая этим уровнем ассоциаций, и вы не возражаете, чтобы вручную вводить повторяющиеся данные (вы можете в конечном итоге реализовать автоматическую систему, чтобы помочь вам), вы можете замаскировать часть нормализации ограничения.

Нормализация - всего лишь предложение. Выберите, какое право для вас и учитесь на своих ошибках.

Основной концепцией нормализации является идея, что вы должны хранить только одну копию любого элемента данных, который у вас есть. Похоже, вы уже неплохо начали.

Есть два основных способа моделирования того, что вы пытаетесь сделать здесь, с эпизодами и шоу. В мире баз данных мы могли бы услышать термин "один ко многим" или "многие ко многим". Оба они полезны, это зависит только от конкретной ситуации, чтобы знать, какая из них правильная. В вашем случае, большой вопрос, чтобы задать себе вопрос, может ли один эпизод принадлежать только одному шоу, или эпизод может принадлежать сразу нескольким шоу? Я объясню две формы и почему вам нужно знать ответ на этот вопрос.

Первая форма - это просто отношение внешнего ключа. Если в таблице эпизодов есть две таблицы, "эпизоды" и "показы", ​​у вас будет столбец с именем "show_id", который содержит идентификатор одного (и только одного!) Шоу. Вы видите, как вы никогда не могли бы иметь эпизод, принадлежащий более чем одному шоу таким образом? Это называется отношением "один к многим", т.е. Шоу может иметь много эпизодов.

Вторая форма - использовать таблицу ассоциации, и это форма, которую вы использовали в вашем примере. Эта форма позволит вам связать эпизод с несколькими шоу и поэтому называется отношением "многие ко многим".

Существует некоторая польза от использования первой формы, но в большинстве случаев это не очень большая сделка. Ваши запросы будут немного короче, потому что вам нужно присоединиться только к двум таблицам, чтобы получить эпизоды → показы, а другая таблица - еще одно соединение. Это действительно сводится к выяснению, нужны ли вам отношения "один-много" или "многие-многие".

Примером ситуации, когда вам понадобится отношение "многие ко многим", было бы, если бы вы моделировали библиотеку и должны были отслеживать, кто проверил, какую книгу. У вас будет таблица книг, таблица пользователей, а затем таблица "книг для пользователей", в которой будут идентификаторы, book_id и user_id, и это будет отношение "многие ко многим".

Надеюсь, что это поможет!