Почему вы не используете внешний ключ? [php + MySQL] - PullRequest
9 голосов
/ 25 февраля 2010

Я работаю над старым веб-приложением, которое моя компания использует для создания опросов. Я посмотрел на схему базы данных через командную строку mysql и подумал, что таблицы выглядят довольно солидно. Хотя я не гуру БД, я хорошо разбираюсь в теории (пройдя несколько курсов по разработке базы данных в моей программе разработки программного обеспечения).

При этом я выгрузил операторы создания в файл SQL и импортировал их в MySQL Workbench и увидел, что они не используют никаких "реальных" внешних ключей. Они будут хранить первичный ключ другой таблицы, как если бы вы использовали FK, но не объявляли его как единое целое.

Так что, видя, как устроена их БД так, как я бы через то, что я знаю (за исключением проблемы с ФК), я задаюсь вопросом, может быть, есть причина этого. Это случай ленивого программирования или вы можете получить некоторое повышение производительности, выполнив всю проверку ошибок программно?

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

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

Ответы [ 6 ]

12 голосов
/ 25 февраля 2010

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

4 голосов
/ 25 февраля 2010

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

Более важно то, что для соответствующих столбцов определены индексы (поэтому в столбцах содержатсяПК другой таблицы должен быть проиндексирован).Это также возможно в MyISAM.

3 голосов
/ 25 февраля 2010

как общие моменты; ключи ускоряют чтение (если они применимы к происходящему чтению, они помогают оптимизатору) и замедляют запись (потому что они добавляют накладные расходы к таблицам).

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

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

2 голосов
/ 25 февраля 2010

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

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

0 голосов
/ 25 февраля 2010

Вот пример из реальной жизни, где я не использую внешний ключ.

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

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

0 голосов
/ 25 февраля 2010

Вам не обязательно использовать внешние ключи.

Если у вас их нет, данные могут стать несогласованными, и вы не сможете использовать каскадные удаления и обновления.

Если они у вас есть, вы можете потерять некоторые пользовательские данные из-за ошибки в ваших операторах SQL, которая возникает из-за изменений схемы.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...