Причины, почему Вы не использовали бы внешний ключ? [php + MySQL]
Я работаю над старым веб-приложением свое использование компании для создания обзоров. Я посмотрел на схему базы данных через mysql командную строку и думал, что таблицы выглядели довольно твердыми. Хотя я не гуру DB, я являюсь хорошо сведущим в теории позади него (взявший несколько курсов проектирования баз данных в моей программе разработки программного обеспечения).
Однако я вывел создать операторы в файл SQL и импортировал их в MySQL Workbench и видел, что они делают нет смысла в любых "фактических" внешних ключах. Они сохранят первичный ключ другой таблицы как Вы, был бы с FK, но они не объявляют это как один.
Так видя, как их DB разработан путем, я был бы через то, что я знаю (минус проблема FK), меня оставляют, задаваясь вопросом это, возможно, существует причина позади него. Действительно ли это - случай ленивого программирования, или Вы могли получить некоторое увеличение производительности путем выполнения всей проверки на ошибки программно?
В случае, если Вы хотели бы пример, у них в основном есть Обзоры, и обзор имеет серию Вопросов. Вопросом является часть обзора, таким образом, это содержит, это - PK в столбце. Это - в значительной степени это, но они используют его везде.
Я ценил бы любое понимание:) (я понимаю, что этот вопрос не мог бы иметь правильного/неправильного ответа, но я больше ищу некоторую информацию о том, почему они сделали бы это, поскольку эта система была довольно тверда с тех пор, как мы начали использовать его так, я ведусь полагать, что эти парни знали то, что они делали),
6 ответов
Первоначальные разработчики могли выбрать использование MyISAM или любой другой механизм хранения, который не поддерживает ограничения внешнего ключа.
MySQL поддерживает только определение фактических отношений внешних ключей в таблицах InnoDB, может быть, у вас MyISAM или что-то еще?
Более важно то, что правильные столбцы имеют индексы, определенные для них (так что те, которые содержат PK другого таблица должна быть проиндексирована). Это также возможно в MyISAM.
В качестве общих положений; ключи ускоряют чтение (если они применимы к выполняемому чтению, они помогают оптимизатору) и замедляют запись (поскольку они добавляют накладные расходы в таблицы).
В подавляющем большинстве случаев улучшение скорости чтения и поддержания ссылочной целостности перевешивает незначительные накладные расходы, которые они добавляют к записи.
Это различие было размыто кэшированием, зеркалированием и т.д., поскольку многие чтения на очень больших сайтах фактически не попадают в "живую" базу данных - но это не очень важно, если вы не работаете на Amazon, Twitter и т.п.
Вот пример из реальной жизни, когда я не использую внешний ключ.
Мне нужен был способ хранения родительско-дочерних отношений, где дочерний элемент может не существовать, а дочерний элемент является абстрактным классом. Поскольку дочерний элемент может быть нескольких типов, я использую одно поле для имени типа дочернего элемента и одно поле для перечисления идентификатора дочернего элемента. Приложение обрабатывает большую часть логики.
Я не уверен, было ли это лучшим дизайнерским решением, но это было лучшее, что я мог придумать в срок. Пока все работает хорошо!
На самом деле вам не обязательно использовать внешние ключи.
Если у вас их нет, данные могут стать непоследовательными, и вы не сможете использовать каскадные удаления и обновления.
При их наличии вы можете потерять некоторые данные пользователей из-за ошибки в SQL-операторах, возникающей при изменении схемы.
Некоторые предпочитают иметь их, некоторые предпочитают жить без них. Реальных преимуществ нет ни в том, ни в другом случае.
В сверхбольших базах данных (тип, поддерживаемый Teradata) вы обнаружите, что они не используют внешние ключи. Причина в производительности. Каждый раз, когда вы записываете в базу данных, чего часто бывает достаточно в хранилище данных, у вас возникают дополнительные накладные расходы, связанные с необходимостью проверки всех fk в таблице. Если вы уже знаете, что это правда, в чем смысл.
Хороший дизайн небольшой базы данных означает, что вы просто вставляете их, но если их не учитывать, можно добиться увеличения производительности.