Objetivo
Garantir consistência de dados sob concorrência usando transações ACID, escolher níveis de isolamento adequados e usar triggers com responsabilidade para automações no banco — sem cair nas armadilhas clássicas de performance e debugging.
Pontos-chave
- Condição de corrida: o porquê das transações existirem (estoque vendido duas vezes, saldo negativo).
- ACID: Atomicity, Consistency, Isolation, Durability — o que cada letra realmente garante.
- Níveis de isolamento: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE — e as 4 anomalias (dirty read, non-repeatable read, phantom read, serialization anomaly).
- BEGIN / COMMIT / ROLLBACK com TRY/CATCH — o esqueleto de toda transação que você vai escrever.
- Locks pessimistas vs otimistas:
SELECT FOR UPDATEvs versionamento (etag/timestamp). Quando usar cada um. - Triggers: gatilhos automáticos em INSERT/UPDATE/DELETE; tabelas mágicas
inserted/deleted; tipos BEFORE/AFTER/INSTEAD OF. - Boas práticas e armadilhas: triggers em cascata, performance, debugging difícil, alternativas (event sourcing, change feed).
Bibliografia recomendada
- Designing Data-Intensive Applications — Martin Kleppmann (capítulo 7: Transactions).
- Microsoft Docs — SQL Server Transaction Isolation Levels.
- PostgreSQL Docs — Concurrency Control.
- Brent Ozar — artigos sobre deadlocks e troubleshooting de locks em SQL Server.