Если в вашей БД нет технических столбцов — вы играете на авось.
Кто создал? Кто удалил? Почему не работает? Где следы?
Без этих ответов вы не владеете своей системой.
Что обязательно добавлять в каждую таблицу
Минимальный набор "технической гигиены":
- created_at, created_by — кто и когда создал
- modified_at, modified_by — кто и когда менял
- deleted / is_active — флаг логического удаления
- deleted_at, deleted_by — когда и кем удалено
Именовать столбцы вы можете по-другому, главное - название предавало назначение столбца
Как это выглядит в SQL
-- Таблица customers
CREATE TABLE demo_customers (
customer_id NUMBER PRIMARY KEY,
name VARCHAR2(100),
region VARCHAR2(50),
created_at DATE DEFAULT SYSDATE,
created_by NUMBER,
modified_at DATE,
modified_by NUMBER,
is_active CHAR(1) DEFAULT 'Y' CHECK (is_active IN ('Y', 'N')),
deleted_at DATE,
deleted_by NUMBER
);
Тот же принцип работает и для продуктов ("demo_products"), и для заказов ("demo_orders"). Всё в исходниках на GitHub.
А теперь по пунктам: что это вам даёт
1. Безопасность
Удалённое — не значит потерянное
В "demo_orders" заказ с "is_active = 'N'" — всё ещё в базе.
Ничего не теряется: просто исключается из бизнес-логики.
Пример: Клиент потребовал восстановить заказ — не проблема
Решение:
UPDATE demo_orders SET is_active = 'Y' WHERE order_id = 101;
2. Аудит
Кто и что сделал — теперь прозрачно
Благодаря "modified_by", "deleted_by", "created_by" можно точно сказать, кто тронул запись и когда.
Пример: Заказ удалён вчера в 14:52?
Решение:
Смотрим "deleted_by = 204"
204 — это оператор, уволенный вчера. Совпадение? Не думаем.
3. Диагностика
Сломалось? Быстрее поймёте где
Ищем последние изменения по "modified_at", анализируем ошибки.
Пример: Вдруг перестали работать скидки по регионам.
Решение:
Фильтруем "demo_products" по "modified_at DESC" — видим, кто внёс правку и в какой категории.
4. Откат
Данные остаются, откат возможен
Пропала запись? А она просто "is_active = 'N'".
Пример: Восстановление удалённого клиента
Решение:
UPDATE demo_customers
SET is_active = 'Y'
, deleted_at = NULL
, deleted_by = NULL
WHERE customer_id = 5;
5. Соответствие регламентам
Особенно важно в B2B и финтехе
Контроль версий, история изменений, soft delete — это не пожелание, а требование политики безопасности и аудита.
Пример: При проверке аудитором система обязана показать, кто создавал и редактировал ключевые данные (например, клиентов или заказы).
Файлы и скрипты
Исходные файлы можно найти в GIT.
Контакты
Написать автору | Telegram | Сайт автора
P.S. Не усложняйте себе жизнь — добавьте пару колонок, и пусть база работает на вас, а не наоборот 😉