Возможный дубликат:
Что не так с внешними ключами?
Я использую MS Sql Server с большой базой данных около 4 ГБ данных.
Я ищу в Интернете, почему я должен использовать внешние ключи. к настоящему времени я только проиндексировал ключи, используемые для объединения таблиц. Производительность все в порядке, dataintegrety не проблема.
Должен ли я использовать внешние ключи? Я получу еще большую производительность с помощью внешних ключей?
Внешний ключ фактически не улучшает производительность, на самом деле они несут небольшое ограничение производительности при всех операциях записи, чтобы обеспечить соблюдение ограничения.
Причина, по которой вы хотите использовать их, заключается в предотвращении деструктивных операций записи. Если у вас их нет, неверный код или плохой оператор sql могут удалить строки, которые, как ожидается, будут там.
Целостность не может быть проблемой сегодня, но это точное отношение, которое делает проблему завтра или через две недели.
Внешний ключ - это прежде всего инструмент для обеспечения целостности базы данных, который не связан со скоростью выполнения.
Если вы уже оптимизировали свой индексный дизайн, то, вероятно, вы уже установили эти индексы, по крайней мере, как неидеальные индексы. Поэтому я бы не ожидал, что изменение производительности произойдет только после установки внешних ключей (в том числе даже необязательного индекса).
Я бы немного подозрительно относился к вашей самодовольности в отношении оптимизации вашего дизайна, хотя, если у вас еще нет этой концепции, пригвожденной.
Прочитайте документацию для внешних ключей с целью понять, что они делают для обеспечения целостности (в любом случае это стоит знать). Затем посмотрите, не отвечает ли это на ваш вопрос более полно.
Что не было упомянуто в более раннем вопросе, связанный с SquareCog ранее - да, ограничения внешнего ключа могут быть болью при очистке данных, пакетных обновлениях, генерации тестовых данных или любых типах операций, когда вы обходите обычную последовательность вещи. Но - вы всегда можете отказаться от ограничений внешнего ключа, прежде чем делать что-то подобное, а затем заново создать их позже (если у вас правильно созданы ваши объекты базы данных, это вряд ли будет никакой дополнительной работой).
Я был ленив, но пришел в зависимости от ограничений внешнего ключа. Есть еще ситуации, когда вы не можете их иметь - как в отношениях между базами данных.
В MySQL вы можете отключить внешний ключ с помощью SET FOREIGN_KEY_CHECKS=0
Существует одна особенность/ограничение, которую внешние ключи привносят в вашу систему, о которой пока не упоминалось. Это логика фиксации/транзакции (это то, что я называю это в любом случае). Если включены внешние ключи, все строки для обновления во всех затронутых таблицах должны присутствовать там, где необходимо выполнить коммит (не вызывать ошибку SQL, нарушающую ограничения внешних ключей).
Если у вас есть код, который работает и "играет быстро и свободно", с фиксацией/транзакциями. Тогда вы можете быть в состоянии исправления, чтобы получить работу с FK в схеме.
Кроме того, Oracle по крайней мере позволяет отключать ограничения (а не просто удалять/удалять). Таким образом, вы можете легко включать и выключать их. Удобный, когда вы хотите выполнять некоторые массовые операции либо с накладными расходами ограничений, либо выполнять некоторую "операцию" на данных, которые имеют промежуточные состояния, которые не смогут скрыть ограничения.
Внешние ключи делают целостность данных лучше, производительность, несколько медленнее при удалении/вставке/обновлении.
В моей последней компании мы решили сохранить целостность/соединения в BL, поскольку это делает изменения в BL проще (думаю, сотни миллионов записей). Если у вас небольшое приложение, я не вижу причин, почему бы не сделать это на уровне данных (db)
Внешние ключи также помогают сохранить вашу базу данных в чистоте, так как вы можете создать каскадную базу данных.