Удаление связанной записи может быть запрещено или затронуть другие строки. Разбираем правила ссылочной целостности и вопросы, которые нужно решить заранее.
Кнопка удаления может затронуть больше одной карточки
Представим условную учебную базу магазина. В одной таблице хранятся клиенты, в другой — заказы с указанием клиента. Администратор хочет удалить ненужную карточку и ожидает, что исчезнет только она. Но связанные заказы всё ещё обращаются к этой записи. Как поступить с такой связью, база должна знать заранее.
В учебном руководстве PostgreSQL внешние ключи объясняются через поддержание ссылочной целостности: запись не должна ссылаться на отсутствующий объект. Базовое устройство связи объясняется в материале о первичном и внешнем ключах. Здесь рассмотрим следующий вопрос: что делать, когда запись, на которую ссылаются, действительно хотят удалить? Обычного совпадения номеров для понимания последствий недостаточно.
Поведение зависит от заданного правила
В документации PostgreSQL описано несколько действий для удаления связанной записи. Можно запретить её удаление, пока существуют обращения к ней. Каскадное действие автоматически удаляет ссылающиеся строки. Ещё один вариант — оставить строки и убрать значение ссылки, если это допускают остальные ограничения таблицы.
Для нашей учебной базы эти варианты дадут разные результаты. При запрете карточка клиента и заказы останутся. При каскадном удалении исчезнут и связанные заказы. При допустимом снятии ссылки заказы сохранятся, но прежняя связь с клиентом больше не будет заполнена. Название «связанные данные» само по себе не определяет, какой из этих результатов требуется владельцу системы.
Зависимость по смыслу важнее удобства одной операции
Позиции условного заказа могут рассматриваться как его составные части: без самого заказа их хранение в выбранной учебной модели не нужно. А сведения о совершённой покупке могут иметь самостоятельное назначение для отчёта. Поэтому одинаковое каскадное поведение для любых связей было бы необоснованным решением. Каждую зависимость нужно обсуждать по её смыслу.
Предложим команде сформулировать ожидаемое состояние после удаления словами. Например: учебная карточка недоступна, но сведения об операциях должны остаться пригодными для анализа. Затем специалист проверяет, как это требование выразить в выбранной модели. Простой выбор самой удобной кнопки не заменяет решения о том, какие сведения действительно разрешено потерять.
Скрытие карточки и физическое удаление различаются
Для нашего проекта можно отдельно обсудить прекращение использования карточки: перестать предлагать её для новых операций, сохранив прежние связи. Это предлагаемый вариант жизненного цикла, а не автоматическая возможность любой программы. Если он подходит задаче, нужно определить, где виден статус и как отчёты отличают действующие записи от прежних.
Такое обсуждение не даёт универсального ответа о сроках хранения или удалении персональных данных: здесь рассматривается устройство учебной базы. Техническая сохранность ссылок и организационное решение о допустимости хранения — разные вопросы. Для практической системы команда согласует оба, а в вымышленном примере достаточно явно назвать, какие записи остаются и зачем.
Цепочку последствий проверяют на небольшом примере
Возьмём условного клиента с двумя заказами, у каждого из которых несколько позиций. До любого изменения выпишем ожидаемые судьбы всех трёх типов записей: клиента, заказов и позиций. Если связь продолжается дальше, её тоже нужно учесть. Так становится видно, почему удаление одной карточки способно оказаться более широкой операцией, чем предполагал пользователь.
Проверку лучше обсуждать на отдельном учебном наборе, где известен ожидаемый результат. Транзакция помогает рассматривать связанные изменения как согласованную операцию, но она не выбирает правильную бизнес-политику вместо команды. Согласованно выполненное действие всё равно может оказаться нежелательным, если исходное требование было сформулировано неверно.
Что спросить перед настройкой связи
Уточните, может ли связанная запись существовать самостоятельно, нужно ли сохранять прошлые события и что должны увидеть пользователи после изменения. Затем попросите специалиста показать, какое правило фактически действует и где оно проверено. Для учебного разбора полезнее один понятный сценарий с ожидаемым итогом, чем перечень технических названий без объяснения последствий.
Изучать правила хранения и связи таблиц можно на курсе «SQL инженер». Первый шаг — ответить на вопрос о конкретном примере: какие сведения останутся после удаления карточки и почему именно такой результат нужен вашей задаче.
