MySQL - полезны ли / полезны ли FK в веб-приложении?

Question

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

Что вы, ребята, думаете, каков ваш опыт?

edit : обратите внимание, что мне известны работа и цель FK, я просто не уверен, что они окажут значительное негативное влияние на производительность веб-приложения, такого как youtube или чего-то подобного.

-

Цитата из Хейкки Туури , создателя движка InnoDB, основателя и генерального директора Innobase:

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

Иностранные ключи увеличивают количество строк блокировка уровня выполнена и может сделать это распространяться на множество таблиц, кроме те, которые непосредственно обновляются

Answer 1

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

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

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

Кроме того, в качестве дополнительного примечания, хотя оно и не имеет прямого отношения к MySQL, это цитата из Шаблоны и практики Microsoft: Глава 14 Повышение производительности SQL Server :

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

Answer 2

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

Answer 3

Помимо всех веских причин, упомянутых здесь (на самом деле есть нет причин их не использовать), есть еще одна веская причина:

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

Answer 4

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

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

(*: если вы не используете транзакции. Но давайте посмотрим правде в глаза, если вы тот тип автора, который занимается настройкой веб-приложений без ссылочной целостности, вы вряд ли тоже будете использовать транзакции.)

Answer 5

Внешние ключи являются полезным барьером между вами и проблемами целостности данных.Они просят базу данных выполнить дополнительную работу от вашего имени, чтобы УБЕДИТЬСЯ, что целостность, которую вы определяете, соблюдается, независимо от того, насколько сильно испорчен какой-то код приложения.Это спасло шею каждого программиста БД хотя бы раз в их карьере.Вы должны полностью спроектировать внешние ключи в своей модели, , особенно , если вы считаете, что они вам не нужны.

Тем не менее, если вы расширяете пределы масштабируемости на уровне базы данных,FK могут быть чем-то, что вы отключаете, потому что в теории , они выполняют дублирующую работу, которую ваше приложение уже выполняет (то есть ваше приложение не должно быть закодировано, чтобы преднамеренно делать вещи, которые нарушают целостность отношений, если бы не ФК).Это не для слабонервных, и в этом отношении, это не ВСЕГДА выигрыш в производительности (некоторые JOIN более эффективны, потому что DB знает, могут ли определенные отношения иметь или не иметь результирующие строки).

Как и во всей оптимизации, правило 1 - «Не делай этого», а правило 2 - «Не делай этого (пока)».Убедитесь, что, если вы идете по этому пути:

1) у вас есть данные о конкретной загрузке производительности для подтверждения вашего решения

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

3) у вас есть возможность периодически проверять, что ограничения целостностиВы разработали правильное применение кода приложения (например, ночная работа, которая проверяет, что нет сирот)

Answer 6

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

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

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

ИМХО, выигрыш в производительности (если есть ??) не стоит потенциального риска нарушения целостности вашей базы данных.

Answer 7

Ваш вопрос - все равно что утверждать, что гоночным машинам не нужны рулевые колеса, потому что это замедляет их - бессмысленно. Все автомобили нуждаются в руле (по крайней мере, автомобили, которые построены сегодня). Другие уже подробно объяснили, почему внешние ключи полезны для целостности данных. Кроме того, я хотел бы отметить, что современные языки и платформы могут использовать метаданные внешнего ключа в базе данных для установления объектных отношений. Linq-to-SQL делает это очень элегантно. Вы не можете по-настоящему работать со структурой объектно-реляционного отображения, не определяя внешние ключи всякий раз, когда отношения данных требуют их.

Answer 8

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

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