Пользователь жмет кнопку «Удалить профиль» и наивно полагает, что его данные испарились. На деле в 90% случаев мы просто вешаем на запись ярлык
is_deleted = true и прячем её от логики фронтенда. Это называется Soft Delete. И со стороны это выглядит как заговор корпораций, жаждущих владеть информацией вечно, но реальность куда прозаичнее: данные — это фундамент, на котором держится бизнес-логика и отчетность.
Эффект домино и целостность системы
Представьте интернет-магазин. У вас есть заказы, транзакции, складские остатки. Если вы сделаете честный Hard Delete — то есть реально выполните
DELETE FROM users — в базе сработают каскадные связи (Foreign Keys). В худшем сценарии это вызовет «эффект домино»: вместе с юзером по цепочке вы удалите половину базы — его заказы, историю оплат и логистические записи.Когда к вам придет налоговая с вопросом, откуда взялись деньги на счету, а в базе зияет дыра вместо истории транзакций, потому что «клиент так захотел», объясняться будет поздно. Данные — это ваша машина времени. Soft Delete позволяет расследовать инциденты, восстанавливать случайно удаленные записи и сохранять консистентность аналитики, не превращая структуру базы в швейцарский сыр.
Техническая подкапотка: Флаги и метки
В нормальном продакшне вместо булевого флажка
is_deleted (true/false) чаще используют deleted_at с типом timestamp. Это дает больше контекста: мы не просто знаем, что запись удалена, но и видим точное время «смерти». Если в базе данных NULL — запись жива. Если стоит время — она в архиве.Но за эту гибкость приходится платить сложностью разработки:
1. Фильтрация: Теперь в каждый запрос к базе нужно не забыть добавить
WHERE deleted_at IS NULL. Забудете в одном месте — и удаленный товар внезапно всплывет в поиске или корзине.2. Уникальные индексы: Это главная боль. У вас стоит констрейнт на уникальность e-mail. Юзер удалил аккаунт (Soft Delete), запись осталась в таблице. Через неделю он пытается зарегистрироваться снова на ту же почту, и база выдает ошибку: «E-mail уже занят».
Инженерам приходится выкручиваться: либо включать
deleted_at в составной уникальный индекс, либо очищать поле e-mail при удалении, чтобы не забивать уникальный слот.GDPR против архитектуры
Но жизнь нам усложняют и юридические нормы, например, европейский GDPR с его «правом на забвение». Если пользователь требует удалить данные, мы обязаны их именно удалить, а не просто скрыть. Но как это сделать, не разрушив финансовую отчетность?
Решение — анонимизация. Мы стираем персональные данные (имя, телефон, почту, адрес), превращая запись в «Анонимного пользователя №404», но сохраняем саму сущность и её связи с транзакциями. Так закон соблюден, а база не рассыпалась.
Инженерная работа — это вечный поиск баланса между юридическими нормами, чистотой кода и целостностью данных. Мы не просто пишем код, мы строим систему, которая должна выжить, даже если пользователь решит из неё уйти.
🔥 — если итак никогда ничего не удалял. А если остались вопросы по реализации или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК | ВЕБМастер