Bases de datos relacionales
Los cuatro pilares que garantizan que tus transacciones sean correctas, seguras y confiables.
Todo o nada — la transacción completa o no ocurre
Una transacción es un conjunto de operaciones que deben ejecutarse como una unidad indivisible. Si cualquier paso falla, todas las operaciones se revierten como si nunca hubieran ocurrido. No existen estados intermedios visibles para el mundo exterior.
El ejemplo clásico: una transferencia bancaria implica dos operaciones — debitar cuenta A y
acreditar cuenta B. Si el sistema falla después del débito pero antes del crédito, el dinero
desaparecería. La atomicidad garantiza que eso nunca pase.
La base de datos siempre pasa de un estado válido a otro válido
Consistencia significa que toda transacción debe respetar las reglas de integridad definidas
en el esquema: restricciones de tipo, NOT NULL, UNIQUE, claves foráneas,
rangos válidos, y cualquier regla de negocio programada. Si una transacción viola alguna de estas
reglas, es rechazada automáticamente — la base de datos nunca queda en un estado inválido.
A diferencia de atomicidad (que habla de cuántas operaciones), consistencia habla de qué valores son aceptables. Son complementarias: una transacción puede ser atómica pero igualmente violar una restricción y ser rechazada.
Las transacciones concurrentes no se interfieren entre sí
Cuando múltiples transacciones corren al mismo tiempo, el aislamiento garantiza que cada una vea la base de datos como si fuera la única en ejecución. Sin él, aparecen tres anomalías clásicas que pueden corromper los resultados sin que nadie lo note.
SQL define cuatro niveles de aislamiento que controlan qué anomalías se permiten. A mayor nivel, mayor consistencia, pero también mayor contención y menor concurrencia.
| Nivel | Lectura sucia | No repetible | Fantasma |
|---|---|---|---|
| Read Uncommitted | posible | posible | posible |
| Read Committed (default en PG) | evitado ✓ | posible | posible |
| Repeatable Read (default en MySQL) | evitado ✓ | evitado ✓ | posible |
| Serializable | evitado ✓ | evitado ✓ | evitado ✓ |
Un COMMIT confirmado sobrevive cualquier fallo del sistema
Una vez que la base de datos responde COMMIT, esos datos están guardados para siempre —
aunque haya un corte de luz un segundo después. El mecanismo que hace posible esto es el
Write-Ahead Log (WAL): antes de modificar cualquier dato en disco, se escribe primero
la operación en un log secuencial persistente. Al reiniciar tras un fallo, el motor lee el log y
reconstruye el estado correcto.
El fsync es la operación que fuerza al sistema operativo a vaciar sus buffers internos y
escribir realmente en el disco físico. Sin él, el SO podría mantener los datos en RAM y perderlos
ante un fallo. Por eso los motores de base de datos son deliberadamente lentos en confirmaciones —
sin fsync no hay durabilidad real.
Las cuatro propiedades funcionan juntas. Una transacción correcta necesita las cuatro: A garantiza que no queden operaciones a medias, C que los datos sean válidos, I que las transacciones paralelas no se contaminen, y D que nada se pierda.