Недостатком не является использование внешних ключей SQL

Question

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

Теперь я заметил, что таблицы не связаны друг с другом через внешние ключи, но только что добавил столбец, например priceListID = 01124, который совпадает с Id в таблице прайс-листов.Поэтому связывание данных должно происходить внутри кода путем запуска различных операторов выбора, которые я предполагаю.

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

Надеюсь, вы поможете мне с этим!Большое спасибо!

Answer 1

Сохранение таких ограничений внутри базы данных дает несколько преимуществ:

1. Производительность.Большинство ограничений, таких как внешние ключи, лучше реализуются, если они хранятся в базе данных, близко к данным.Вы хотите проверить целостность данных с помощью дополнительных select?Вы должны сделать дополнительный запрос к базе данных.Это требует некоторого времени.
2. Что если у вас есть несколько приложений, которые работают с вашей базой данных?Вы должны написать код для проверки целостности данных во всех из них, что подразумевает дополнительные расходы.
3. Синхронизация.Пока вы проверяете целостность данных с помощью дополнительного выбора, другой пользователь может удалить эти данные одновременно.И вы не будете знать об этом.Конечно, эти проверки могут быть правильно реализованы, но это все еще дополнительная работа, которую вы должны сделать.

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

Answer 2

Из вашего описания я понимаю, что таблицы действительно функционально связаны , поскольку они совместно используют общую информацию (priceListID в новой таблице относится к id в исходной таблице).С одной стороны, эта установка все еще позволяет писать запросы, объединяющие таблицы.

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

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

Это должно быть так просто, как:

ALTER TABLE newtable
    ADD CONSTRAINT fk_new_to_original_fk 
    FOREIGN KEY (priceListID ) 
    REFERENCES originaltable(id);

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