В то время, когда я учился в колледже, первый проект системы управления библиотекой ssm, над которым я работал, фактически не реализовывал внешние ключи в базе данных, тогда это рассматривалось на прикладном уровне.
Используете ли вы внешние ключи при разработке базы данных? - Ответ Линь Имэна - Чжиху https://www.zhihu.com/question/19600081/answer/177410355
Почему не рекомендуется использовать ограничения внешнего ключа — Zhihu (zhihu.com)
Ограничение внешнего ключа является своего рода ограничением Существование этого ограничения гарантирует, что связь данных между таблицами «всегда завершена». Следовательно, существование ограничений внешнего ключа не лишено преимуществ.
Например, используя внешние ключи, вы можете
- Обеспечение целостности и согласованности данных
- Каскадный режим удобен
- Оценка целостности данных возложена на базу данных, что уменьшает объем кода в программе.
Тем не менее, вы не можете иметь свой торт и съесть его тоже. Внешние ключи могут обеспечить целостность данных, но принесут в систему множество дефектов. Именно из-за этих дефектов мы не рекомендуем использовать внешние ключи, как показано ниже.
проблема производительности
Предположим, есть таблица с именем user_tb. Затем в этой таблице есть два поля внешнего ключа, указывающие на две таблицы. Затем каждый раз, когда вы вставляете данные в таблицу user_tb, вы должны запрашивать, есть ли соответствующие данные в таблицах, соответствующих двум внешним ключам. Если он управляется программой, то этот процесс запроса может контролироваться в наших руках, а некоторые ненужные процессы запроса могут быть опущены. Но если это контролируется базой данных, то надо судить по этим двум таблицам.
проблемы параллелизма
В случае использования внешних ключей каждый раз, когда вы изменяете данные, вам нужно переходить к другой таблице для проверки данных, и вам необходимо приобретать дополнительные блокировки. В сценариях с высокой степенью параллелизма и большого трафика использование внешних ключей с большей вероятностью приведет к взаимоблокировкам.
проблемы с масштабируемостью
В основном есть два момента
- Удобно выполнять миграцию платформы. Например, при
Mysqlмиграции наOracle, такие вещи, как триггеры и внешние ключи, можно реализовать, используя характеристики самого фреймворка, а не полагаясь на характеристики самой базы данных. Миграция более удобна. - Это удобно для подбазы данных и подтаблицы.В случае горизонтального разделения и подбазы данных внешние ключи не могут действовать. Включение поддержания взаимосвязи между данными в прикладную программу избавит от многих проблем для будущих подбаз данных и подтаблиц.
техническая проблема
Использование внешних ключей фактически передает логику оценки, которую должно выполнять приложение, в базу данных. Тогда это означает, что накладные расходы на производительность базы данных стали больше, а это предъявляет более высокие требования к администратору баз данных. Многие малые и средние компании не нанимают профессиональных администраторов баз данных из-за проблем с финансированием, поэтому они предпочитают не использовать внешние ключи, чтобы уменьшить потребление базы данных.
Наоборот, если логика ограничений находится в прикладной программе, а производительность сервера приложений недостаточна, можно добавить машины для горизонтального расширения. Если он находится на сервере базы данных, сервер базы данных станет узким местом в производительности, что затруднит горизонтальное масштабирование.