Чистое решение для удаления записи в родительской таблице при удалении записи в дочерней таблице (Oracle) - PullRequest
1 голос
/ 17 октября 2019

В настоящее время я работаю над этой базой данных Oracle, и для простоты у меня есть три таблицы: user, address, address_detail. Каждый адрес имеет внешний ключ к идентификатору пользователя и ad_id. Все записи address_detail должны быть уникальными. Пример ниже:

create table user (
user_id number not null,
primary key user_id
)

create table address (
address_id number not null,
user_id    number not null,
ad_id      number not null,
primary key address_id,
foreign key user_id references user (user_id) on delete cascade,
foreign key ad_id references address_detail (ad_id)
)

create table address_detail (
ad_id number not null,
primary key ad_id
)

Проблема, которую я пытаюсь элегантно решить (или, по крайней мере, самое лучшее из доступных решений), заключается в сохранении целостности таблиц при удалении пользователя. Если пользователь удален, запись адреса будет удалена, а запись address_details останется сиротой. В настоящее время большинство всех операций обрабатываются с помощью хранимых процедур и обрабатывают проверку целостности;тем не менее, у нас есть некоторые пакетные задания (с древних времен), которые непосредственно выполняют операторы DML. Одна из этих работ оставила запись о сиротах, и я пытаюсь предотвратить это. Я могу придумать следующие решения:

  • триггеры при удалении = Раньше у нас были триггеры, но они стали ненадежными, и я пытался избежать их использования.
  • добавив еще одинcolumn = Мысль о добавлении столбца для «user» или «address» в таблицу «address_details» с ограничением каскадного удаления. Хотя это будет работать, мне не нравится иметь столбец только для этого
  • добавление проверки целостности в процедуре = Процедуры, которые вызываются при добавлении адреса, могут быть изменены для автоматической проверки на наличие сирот. Если сирота существует, она регистрирует данные / событие и удаляет их. Я полагал, что это может быть частью проверки правильности, когда проверяется, что запись address_details еще не существует (поскольку все записи в AD должны быть уникальными, это предотвратит отправку ошибки, сообщающей, что запись уже существует, когда она не должна '). т.

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

Спасибо за помощь

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...