Aula 5 — Material

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 UPDATE vs 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.