Технические столбцы в таблице

Если в вашей БД нет технических столбцов — вы играете на авось. Кто создал? Кто удалил? Почему не работает? Где следы?

Без этих ответов вы не владеете своей системой.

Минимальный набор "технической гигиены":

1. created_at, created_by — кто и когда создал

2. modified_at, modified_by — кто и когда менял

3. deleted / is_active — флаг логического удаления

4. deleted_at, deleted_by — когда и кем удалено

Именовать столбцы вы можете по-другому, главное - название предавало назначение столбца

-- Таблица 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.

Удалённое — не значит потерянное!

В "demo_orders" заказ с "is_active = 'N'" — всё ещё в базе.

Ничего не теряется: просто исключается из бизнес-логики.

Пример: Клиент потребовал восстановить заказ — не проблема

Решение:

UPDATE demo_orders SET is_active = 'Y' WHERE order_id = 101;

Кто и что сделал — теперь прозрачно

Благодаря "modified_by", "deleted_by", "created_by" можно точно сказать, кто тронул запись и когда.

Пример: Заказ удалён вчера в 14:52?

Решение:

Смотрим "deleted_by = 204"
204 — это оператор, уволенный вчера. Совпадение? Не думаем.

Сломалось? Быстрее поймёте где

Ищем последние изменения по "modified_at", анализируем ошибки.

Пример: Вдруг перестали работать скидки по регионам.

Решение:

Фильтруем "demo_products" по "modified_at DESC" — видим, кто внёс правку и в какой категории.

Данные остаются, откат возможен

Пропала запись? А она просто "is_active = 'N'".

Пример: Восстановление удалённого клиента

Решение:

UPDATE demo_customers SET is_active = 'Y' , deleted_at = NULL , deleted_by = NULL WHERE customer_id = 5;

Особенно важно в B2B и финтехе

Контроль версий, история изменений, soft delete — это не пожелание, а требование политики безопасности и аудита.

Пример: При проверке аудитором система обязана показать, кто создавал и редактировал ключевые данные (например, клиентов или заказы).

github.com

blog/create-database-tables/sql/02_create_tables.sql at main · aldabaeva/blog

P.S. Не усложняйте себе жизнь — добавьте пару колонок, и пусть база работает на вас, а не наоборот 😉

#oracle #автоматизация

Технические столбцы в таблице

Что обязательно добавлять в каждую таблицу

Как это выглядит в SQL

А теперь по пунктам: что это вам даёт

1. Безопасность

2. Аудит

3. Диагностика

4. Откат

5. Соответствие регламентам