Многие проекты добавляют в таблицы колонку deleted или archived_at, чтобы не удалять данные окончательно. Звучит удобно: пользователь случайно что-то удалил — можно восстановить. Но на практике это создаёт массу проблем.
Основные проблемы классического подхода
Мёртвые данные в живых таблицах. 99% архивных записей никогда не будут прочитаны, но они постоянно болтаются рядом с актуальными данными.
Каждый запрос должен фильтровать
WHERE archived_at IS NULL. Индексы раздуваются. Миграции данных становятся сложнее — надо ли обрабатывать записи двухлетней давности? Всегда есть риск, что архивные данные случайно попадут туда, где их быть не должно.Создание записи затрагивает внешние системы. Восстановление может требовать сложной логики, которая всегда будет неполной копией API создания. Старые данные могут не пройти новые правила валидации.
Альтернативные подходы
• Архивирование на уровне приложения
При удалении записи приложение отправляет событие в очередь, а отдельный сервис сохраняет архивные данные в другом месте.
Плюсы: основная БД остаётся простой, удаление асинхронное (быстрее и надёжнее), данные можно сериализовать в удобном формате.
Минусы: легко допустить баг и потерять архивные данные, больше инфраструктуры, сложнее искать записи для восстановления.
• Триггеры PostgreSQL
Создаём универсальную таблицу archive, которая хранит JSON-представление удалённых записей:
CREATE TABLE archive (
id UUID PRIMARY KEY,
table_name TEXT NOT NULL,
record_id TEXT NOT NULL,
data JSONB NOT NULL,
archived_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
Триггер автоматически копирует удаляемую строку в архив. Можно даже отслеживать каскадные удаления через session variables.
• Реплика без DELETE
Держать логическую реплику, которая игнорирует DELETE-запросы или превращает их в archived_at.
➡️ Источник
📍 Навигация: Вакансии • Задачи • Собесы
🐸Библиотека шарписта
#il_люминатор