Удалить объект из графа объектов с сохранением целостности

Question

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

Например, когда продукт удаляется, что является лучшим подходом, чтобы убедиться, что заказы, содержащие этот продукт, по-прежнему актуальны, или, кроме того, все счета-фактуры, содержащие заказы, содержащие этот продукт, по-прежнему актуальны?

Answer 1

Есть в основном 3 «стандартные решения»:

Решение 1

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

Если вы заинтересованы в производительности, выполните некоторые профилирования ... если вам потребуется множество вариантов оптимизации. .. это, как правило, RDBMS-зависимый, один метод является «разделение» - каждый СУБД имеет свои собственные механики, которые отличаются гибкостью и т.д.

Решение 2

Вам не нужно каких-либо данных в все ... просто сделайте каскадное удаление и сделайте с ним ...

Решение 3

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

Заключение

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

Answer 2

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

Я не собираюсь принимать свой собственный ответ здесь или обходить щедрость, но просто показываю его ответ.

«С полнофункциональной РСУБД вы можете разбить таблицу на столбце« deleted_or_not », и это приведет к компактному хранению всех живых производственных строк. Если вы не хотите, чтобы устаревшие данные отображались в отчетов, просто дайте полной таблице неясное имя, например clients_including_deleted_rows, и создайте представление «клиенты» (содержащее только прямые строки), из которого выполняется большинство запросов кода приложения. Это предполагает, конечно, что есть некоторая ценность для того, чтобы иметь старые данные вокруг."