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

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

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

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

1. created_at, created_by — кто и когда создал
2. modified_at, modified_by — кто и когда менял
3. deleted / is_active — флаг логического удаления
4. deleted_at, deleted_by — когда и кем удалено

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

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

— Таблица клиентов
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 — это не пожелание, а требование политики безопасности и аудита.

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

Выводы

Технические поля — это не «для галочки». Это фундамент стабильности вашей БД.

1. Что это вам даёт?
2. Логи в БД — это ваша "черная коробка"
3. Удобство в отладке и расследованиях
4. Простота при написании триггеров и аналитики
5. Меньше ручной работы, если всё автоматизировать

Даже если сейчас всё «маленькое и простое» — через полгода вы скажете себе спасибо, что добавили эти поля.

Файлы и скрипты

Исходные файлы можно найти в GIT.

Контакты

Написать автору | Telegram | Сайт автора

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