Когда использовать внешний ключ в MySQL

Question

Существует ли официальное руководство или пороговое значение, указывающее, когда рекомендуется использовать внешний ключ в базе данных MySQL?

Предположим, вы создали таблицу для фильмов. Один из способов сделать это - объединить данные производителя и директора в одну таблицу. (movieID, movieName, имя_директора, имя_производителя).

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

Когда это станет лучшей практикой для этого? Когда многие режиссеры и продюсеры появляются несколько раз в колонке? Или лучше всего использовать подход с внешним ключом с самого начала? Хотя использование внешнего ключа кажется более эффективным, оно также повышает сложность базы данных.

Итак, когда компромисс между сложностью и нормализацией становится оправданным? Я не уверен, есть ли порог или определенное количество повторений ячеек, что делает более разумным использование внешнего ключа.

Я думаю о базе данных, которая будет использоваться сотнями пользователей, многие одновременно.

Большое спасибо!

Answer 1

есть некоторые официальные рекомендации для этого. они называются нормальными формами, а практика помещения в них вашей базы данных называется нормализацией: http://en.wikipedia.org/wiki/Database_normalization

если вы будете учиться в колледже, они, вероятно, научат вас 3nf или bcnf. Я всегда находил эти подходы немного сложными, но у меня достаточно опыта в разработке БД, и я считаю, что эти вопросы в основном интуитивно понятны на этом этапе ...

в вашем примере вы определенно хотите использовать ограничения внешнего ключа. отношения многих к одному лучше всего выражены таким образом. это сделает выбор фильмов немного медленнее, потому что вам придется выполнить объединение на таблице «люди» и таблице «фильмы» - возможно, будет много объединений в зависимости от того, сколько полей «люди» имеет таблица «фильмы».

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

не забывайте, если вы хотите использовать внешние ключи, вы должны сделать ваши таблицы innodb в mysql.

Answer 2

Предположим, вы создали таблицу для фильмы. Один из способов сделать это интегрировать продюсера и режиссера данные в одну таблицу. (MovieID, movieName, DirectorName, producerName).

Это слишком ненормально. Вы повторяете данные.

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

Также предположим, что человек может работать над одним фильмом в качестве продюсера, а другой - в качестве режиссера. Один человек также может быть зачислен в качестве режиссера, продюсера, писателя и актера в одном фильме!

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

Вы с самого начала захотите освоить внешние ключи, отношения (особенно 1-ко-многим и многие-ко-многим) и нормальные формы. Они быстро станут второй натурой.