Soft Delete, Hard Delete или Архив? Как правильно удалять данные 🗑️ Задача: Пользователь нажал «Удалить аккаунт». Что делать базе? Стереть навсегда? Скрыть? Или перенести в чулан? Разбираем три стратегии. 1️⃣ Hard Delete (Физическое удаление) 🧨 Классический DELETE. Данные исчезают, место освобождается. Плюсы: 🔹 Максимальная скорость работы базы (таблицы компактные). 🔹 Соблюдение GDPR (право на забвение). 🔹 Нет проблем с уникальностью (email можно использовать повторно сразу). Минусы: Данные не восстановить без бэкапа. Опасность «битых ссылок», если забыли настроить каскадное удаление (Foreign Keys). 2️⃣ Soft Delete (Мягкое удаление) 👻 Мы не удаляем строку, а ставим метку deleted_at = NOW(). Данные лежат на месте, но приложение делает вид, что их нет. Плюсы: 🔹 Легко восстановить («Ой, я случайно!»). 🔹 Сохраняется история и связи. Минусы: 🔸 Раздувание таблицы: База хранит тонны «мертвых» данных, индексы тормозят. 🔸 Сложность запросов: Везде нужно писать WHERE deleted_at IS NULL. 🔸 Проблема уникальности: Если bob@site.com удален «мягко», создать нового Боба с тем же email не даст уникальный индекс (нужен частичный индекс). 3️⃣ Archiving (Архивирование / Cold Storage) 📦 Гибридный подход. Данные удаляются из основной («горячей») таблицы, но перед этим переносятся в отдельную таблицу-архив (users_archive). Как это работает: 🔹Стартуем транзакцию. 🔹INSERT данные в таблицу архива. 🔹DELETE данные из основной таблицы. 🔹Коммит. Плюсы: ✅ Основная таблица летает (в ней только активные данные). ✅ История сохранена (в архиве). ✅ Нет проблем с уникальными индексами в основной таблице. Элегантный перенос одной командой (PostgreSQL) : WITH moved_rows AS ( DELETE FROM users WHERE id = 101 RETURNING ) INSERT INTO users_archive SELECT FROM moved_rows;