переопределить ограничение от бездействия до каскадирования во время выполнения

Question

Я чувствую, что у меня очень простой / глупый вопрос, но я никогда ничего не видел / не читал / не слышал в этом направлении.

Допустим, у меня есть таблица пользователей (userId, имя) и таблица предпочтений (id, userId, language) . Пример тривиален, но его можно распространить на ситуацию с многоуровневыми отношениями и несколькими таблицами.
Когда мой пользовательский интерфейс запрашивает удаление пользователя, я сначала хочу показать предупреждение о том, что также будут удалены его настройки. Если в какой-то момент база данных расширяется за счет большего количества таблиц и связей, но программное обеспечение не адаптируется соответствующим образом (клиент не обновил), должно отображаться общее сообщение.

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

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

Почему-то я чувствую, что все неправильно понимаю ...

Answer 1

Что бы я сделал, это:

1. Ограничение - КАСКАД
2. Приложение проверяет наличие предпочтений.
3. Если они это сделают, покажите предупреждение.
4. Если предпочтений нет или предупреждение принято, удалите клиента.

Изменение базы данных на лету не будет хорошей идеей !!

Приветствия

RB.

Answer 2

Если вы беспокоитесь о том, что пользователь не осознает всех последствий своего удаления, вы можете подумать о том, чтобы на самом деле не удалять данные - вместо этого вы можете просто установить флаг в столбце с именем «marked_for_deletion». (записи могут быть удалены безопасным временем позже)
Недостатком является то, что вам нужно помнить, чтобы отфильтровать отмеченные строки в других запросах. Этого можно избежать, создав представление таблицы с отфильтрованными отмеченными строками, а затем всегда используя представление в ваших запросах.