Создавал ли триггеры в SQL

Опыт создания триггеров в SQL

Да, я создавал SQL триггеры в production-коде, особенно при работе с PostgreSQL. Хотя триггеры — мощный инструмент, я научился использовать их осторожно, так как они могут усложнить архитектуру и отладку.

Типы триггеров, которые я создавал

1. Аудит и логирование изменений:

CREATE OR REPLACE FUNCTION audit_user_changes()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO audit_log (table_name, operation, old_data, new_data, changed_at)
    VALUES (
        TG_TABLE_NAME,
        TG_OP,
        row_to_json(OLD),
        row_to_json(NEW),
        NOW()
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

2. Обновление timestamp fields:

CREATE OR REPLACE FUNCTION update_modified_timestamp()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = CURRENT_TIMESTAMP;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

3. Каскадные обновления:

CREATE OR REPLACE FUNCTION update_category_count()
RETURNS TRIGGER AS $$
BEGIN
    IF TG_OP = 'INSERT' THEN
        UPDATE categories
        SET item_count = item_count + 1
        WHERE id = NEW.category_id;
    ELSIF TG_OP = 'DELETE' THEN
        UPDATE categories
        SET item_count = item_count - 1
        WHERE id = OLD.category_id;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Когда я использую триггеры

Уместное применение:

• Аудит всех изменений в критических таблицах
• Автоматическое обновление timestamps
• Синхронизация денормализованных данных
• Enforce constraints на уровне БД
• Инкремент/декремент счётчиков

Когда я избегаю триггеров:

• Complex business logic (лучше в application code)
• Когда нужна гибкость и возможность отладки
• Если есть вероятность race conditions
• Когда performance критичен

Лучшие практики

1. Простота и понятность: Триггеры должны быть максимально простыми. Complex business logic лучше в application code.

2. Документирование:

• Комментарии о назначении триггера
• Указание на функцию, которую он вызывает
• Список таблиц, которые он затрагивает

3. Тестирование:

• Unit-тесты для функций
• Integration-тесты всего workflow
• Проверка edge cases

4. Мониторинг:

• Logging ошибок в триггерах
• Мониторинг performance
• Алерты на аномалии

Интеграция с Python/ORM

from sqlalchemy import event
from sqlalchemy.orm import mapper

@event.listens_for(User, 'after_insert')
def receive_after_insert(mapper, connection, target):
    audit_log.log(f'User {target.id} created')

Выводы

Триггеры — это мощный инструмент, но их нужно использовать с осторожностью. Они отлично подходят для простых операций (timestamps, счётчики), но complex business logic лучше держать в application code, где легче тестировать и отлаживать.