Когда использовать внешний ключ в MySQL
Есть ли официальное руководство или порог для указания, когда это - лучшая практика для использования внешнего ключа в базе данных MySQL?
Предположим, что Вы составили таблицу для фильмов. Один способ сделать это состоит в том, чтобы интегрировать данные производителя и директора в ту же таблицу. (movieID, movieName, directorName, producerName).
Однако предположите большинство директоров, и производители работали над многими фильмами. Было бы лучше составить две других таблицы для производителей и директоров, и использовать внешний ключ в таблице фильма?
Когда это становится лучшей практикой, чтобы сделать это? Когда многие директора и производители появляются несколько раз в столбце? Или это - лучшая практика для использования подхода внешнего ключа в запуске? В то время как кажется более эффективным использовать внешний ключ, это также повышает сложность базы данных.
Таким образом, когда делает компромисс между сложностью, и нормализация становятся стоящими того? Я не уверен, существует ли порог или определенное число повторений ячейки, которое делает более разумным использовать внешний ключ.
Я думаю о базе данных, которая будет использоваться сотнями пользователей, многие одновременно.
Большое спасибо!
2 ответа
для этого существуют некоторые официальные рекомендации. они называются нормальными формами, а практика приведения вашей базы данных к ним называется нормализацией: http://en.wikipedia.org/wiki/Database_normalization
если вы пройдете курс по базам данных в колледже, они, вероятно, научат вас 3nf или bcnf. я всегда находил эти подходы немного тяжелыми, но у меня достаточно опыта в проектировании баз данных, чтобы считать эти вопросы в основном интуитивными...
В вашем примере вы определенно хотите использовать ограничения внешнего ключа. Отношения "многие-к-одному" лучше всего выражаются таким образом. Это сделает выбор фильмов немного медленнее, потому что вам придется сделать соединение таблицы "люди" и таблицы "фильмы" - возможно, много соединений, в зависимости от того, сколько полей "люди" есть в таблице "фильмы".
но преимущество в том, что вы можете легко управлять самими людьми. если вы хотите изменить написание имени человека, вам не нужно сканировать всю таблицу в поисках этого человека в каждом поле. вы можете избежать присутствия одного и того же человека в базе данных несколько раз с небольшими различиями в написании. вы можете установить действия, которые нужно предпринять, если человек удален. вы можете легко подсчитать, сколько различных ролей было у человека.
не забудьте, если вы хотите использовать внешние ключи, вы должны сделать ваши таблицы innodb в mysql.
Предположим, вы создали таблицу для фильмы. Один из способов сделать это - интегрировать продюсера и режиссера данные в одну таблицу. (идентификатор фильма, movieName, имя директора, название продюсера).
Это слишком ненормально. Вы повторяете данные.
Однако предположим, что большинство директоров и продюсеры работали над многими фильмами. Было бы лучше создать два других столы для продюсеров и режиссеров, и использовать внешний ключ в фильме table?
Также предположим, что человек может работать над одним фильмом как продюсер, а другой как режиссер. Отдельного человека можно также назвать режиссером, продюсером, сценаристом и актером в одном фильме!
Когда лучше всего сделай это? Когда многие режиссеры и производителей появляются несколько раз в столбце? Или это лучше практика использования внешнего ключа подход на старте? Хотя кажется более эффективно использовать внешний ключ, это также увеличивает сложность база данных.
Вам нужно с самого начала освоить внешние ключи, отношения (особенно «один ко многим» и «многие ко многим») и нормальные формы. Они станут второй натурой в кратчайшие сроки.