Неактивная карточка остаётся в данных и требует правил использования. Объясняем логическое удаление, влияние на отчёты и проверку восстановления.
Карточка может перестать участвовать в новых операциях
Представим условный каталог товаров. Старую упаковку больше не продают, но заказы прошлых месяцев всё ещё ссылаются на её карточку. Команда хочет убрать её из выбора для новых заказов и сохранить возможность понять прежние покупки. Одним из вариантов может быть изменение статуса без физического удаления строки из базы.
Такой подход часто называют логическим, или мягким, удалением. В документации Microsoft EF Core показан признак удаления, по которому строки исключаются из обычного чтения, оставаясь доступными в специальных сценариях. Это пример механизма конкретного инструмента. В нашей учебной модели сначала нужно определить смысл статуса, а уже затем выбирать способ его обработки.
Название статуса должно соответствовать действию
«Снято с продажи», «временно недоступно» и «ошибочно создано» могут требовать разных решений. Если объединить их одним неясным признаком, пользователь не поймёт, почему карточка исчезла из списка. Для условного каталога предложим отдельно записать причину изменения и ожидаемое поведение в новых операциях. История покупок при этом отвечает на собственный вопрос.
Не следует автоматически превращать любой неактивный товар в удалённый. Например, временное отсутствие на складе может закончиться пополнением. В нашем процессе название статуса и право его менять согласуют с владельцем каталога. Техническая возможность скрыть строку не даёт готового ответа о том, какое состояние бизнеса она должна обозначать.
Отчёт должен учитывать назначение выборки
Если обычный список показывает только действующие карточки, это может подходить для нового заказа. Но исторический отчёт по продажам должен отдельно решать, что делать с покупками снятого товара. Если исключить их вместе с карточкой, прошлые итоги могут незаметно уменьшиться. Поэтому правило отбора нужно определять для каждого назначения результата.
В нашем учебном примере проверим два экрана: выбор товара сегодня и отчёт за прошлый месяц. На первом старая упаковка не предлагается, на втором прежняя покупка остаётся объяснимой. Если результаты расходятся с ожиданием, нужно исследовать правила чтения и связи. Не стоит считать исчезновение карточки из одного интерфейса подтверждением правильного поведения всей системы.
Изменение нужно донести до зависимых представлений
Карточка может использоваться в поиске, выгрузке и другом приложении. В документации Azure AI Search отдельно описана политика обнаружения логического удаления по значению столбца. Это пример того, что зависимому поисковому индексу требуется понятное правило обработки такого изменения, а не только обновление исходной таблицы.
Для нашего проекта предложим перечислить места использования каталога и проверить один изменённый товар в каждом нужном представлении. Где-то требуется скрытие, где-то сохранение исторической связи, где-то отдельная подпись. Одинаковая реакция во всех местах не обязательно правильна: важны согласованные последствия. Особенно полезно увидеть, какие копии обновляются позже основного каталога.
Восстановление тоже требует проверки
Предположим, статус изменили ошибочно. Возврат признака может снова сделать карточку видимой, но за время отсутствия могли появиться другая карточка или новые правила каталога. Для условного восстановления сначала проверим причину, связи и допустимость повторного использования. Обратимость одного поля не означает автоматического возвращения всех прежних условий.
Неактивность также не является обещанием полного стирания сведений или гарантией соблюдения требований к хранению. Здесь рассматривается техническое состояние учебной записи. Сроки хранения, доступ и физическое удаление требуют отдельных решений. В частности, сохранённая строка продолжает занимать место и может оставаться доступной тем, кто имеет соответствующий способ чтения.
Начните с наблюдаемых последствий
Запишите, что увидит пользователь после смены статуса, что произойдёт с прежними операциями и как проверяется восстановление. Отличие от физического удаления по связи разобрано в статье о судьбе заказов при удалении клиента. Сохранить объяснение изменения помогает журнал действий.
Продолжить изучение правил хранения можно на курсе «SQL инженер». Для начала достаточно одного условного товара и двух задач: больше не выбирать его для новой продажи и правильно объяснять продажу, которая уже состоялась.
