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

#foreign-keys #relational-database

#внешние ключи #реляционная база данных

Вопрос:

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

  1. Используйте их в качестве сборщика мусора — Установите для всех ограничений значение каскад. Итак, в вашем приложении вы сначала проверяете, есть ли в целевой строке какие-либо «дочерние элементы», и предоставляете пользователю возможность прервать операцию удаления, если нежелательно удалять и зависимые строки.

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

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

Ответ №1:

Существует 2 типичных сценария внешнего ключа:

  • Ассоциация: связать 2 объекта, которые могут существовать сами по себе
  • Композиция: связать дочерний объект с его родительским объектом (дочерний объект существует без родительского объекта, например: заказ и элемент заказа)

Я бы каскадировал только в случае композиции и рассматривал каждый случай ассоциации индивидуально.

Комментарии:

1. Я думаю, что вы ответили не на тот вопрос, или, возможно, я неверно истолковываю ваш ответ… Но моя дилемма применима к обоим вашим случаям. Мой вопрос заключается в том, кто должен обеспечивать целостность, а не в том, должна ли она быть соблюдена или нет. В обоих случаях одна строка зависит от другой; Вопрос в том, кто производит проверку при удалении — база данных или приложение?

2. Я бы полагался на базу данных для обработки каскадных удалений композиции, потому что не имеет смысла сохранять дочерние элементы при удалении родительских. Для ассоциаций логика более сложная и зависит от того, где находятся ваши бизнес-правила. Если они находятся за пределами базы данных, то бизнес-уровень (приложение, сервис) должен позаботиться о каскадировании удалений. Но золотого правила для таких случаев не существует. Когда вы удаляете последнего сотрудника, связанного с отделом, вы удаляете отдел? Может быть, вероятно, нет, это зависит…

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

4. Добро пожаловать, надеюсь, вы получите больше отзывов, чем только мои.