Каковы преимущества определения внешнего ключа

В чем преимущество определения внешнего ключа при работе с инфраструктурой MVC, которая обрабатывает отношение?

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

Есть ли какое-либо преимущество в использовании внешних ключей, которые я претерпеваю, вообще отказавшись от их использования?

Ответ 1

Внешние ключи с ограничениями (в некоторых механизмах БД) обеспечивают целостность данных на низком уровне (уровень базы данных). Это означает, что вы не можете физически создать запись, которая не выполняет отношения. Это просто способ быть более безопасным.

Ответ 2

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

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

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

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

Ответ 3

Внешний ключ гарантирует соответствие соответствующей записи во внешней таблице. Представьте таблицу с именем Books, которая имеет ограничение FK для таблицы с именем Authors. Гарантируется, что каждая книга имеет Author.

Теперь вы можете выполнить запрос, например:

SELECT B.Title, A.Name FROM Books B
INNER JOIN Authors A ON B.AuthorId = A.AuthorId;

Без ограничения FK отсутствующая строка Author приведет к удалению всей строки Book, что приведет к отсутствию книг в вашем наборе данных.

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

Ответ 4

В то время как они могут быть болью при манипулировании данными разработки/тестирования, они избавили меня от хлопот в производстве.

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

Например, если у вас была база данных, связывающая многие записи PhoneNumber с Person, что происходит с PhoneNumber, когда запись Person удаляется по какой-либо причине? Они все равно будут существовать в базе данных, но идентификатор Person, к которому они относятся, больше не будет существовать в соответствующей таблице Person, и у вас есть осиротевшие записи.

Да, вы могли бы написать триггер для удаления PhoneNumber, когда удаляется Person, но это может стать беспорядочным, если вы случайно удалили Person и вам нужно откат.

Да, вы, возможно, помните, чтобы избавиться от записей PhoneNumber вручную, но как насчет других разработчиков или методов, которые вы пишете через 9 месяцев?

Создав внешний ключ, который гарантирует, что любой PhoneNumber связан с существующим Person, вы оба застрахованы от уничтожения этого отношения, а также добавите "подсказки" относительно предполагаемой структуры данных.

Ответ 5

Основными преимуществами являются целостность данных и каскадные удаления. Вы также можете получить выигрыш в производительности, когда они определены, и эти поля будут правильно проиндексированы. Например, вы не сможете создать номер телефона, который не принадлежит контакту, или когда вы удаляете контакт, вы можете установить его для автоматического удаления всех своих телефонных номеров. Да, вы можете сделать эти соединения в своем интерфейсе или среднем уровне, но вы все равно останетесь сиротами, если кто-то запускает обновление непосредственно против сервера, используя SQL, а не ваш пользовательский интерфейс. Часть "хлопот" просто заставляет вас рассмотреть эти соединения, прежде чем делать массовое изменение. FK сохранили мой бекон много раз.