Qué es una transacción de base de datos

Una transferencia es una resta y una suma, en pareja

En la lección anterior dividimos las tablas para que cada dato viviera en un solo lugar. Aun así, hay trabajos que no se terminan cambiando un solo lugar. Una transferencia bancaria es uno de ellos: hay que restar dinero de tu saldo y sumar la misma cantidad al saldo de quien lo recibe.
Esos dos pasos forman una pareja que no se puede separar. Si solo ocurre uno, el dinero desaparece o aparece de la nada. Probemos abajo los dos cambios por separado.

Toca la resta y la suma por separado. Si pulsas solo una, cambia el total de los dos saldos: el dinero desaparece o aparece de la nada.

Si pulsas solo la resta, tu dinero desaparece; si pulsas solo la suma, aparece dinero de la nada. En cualquier caso, el total de los dos saldos ya no es el del principio. Una transferencia solo mueve dinero, así que el total debería quedar igual.
El peligro está en el breve hueco entre la resta y la suma. Si en ese hueco se corta la luz o el programa se detiene, las cuentas quedan descuadradas. Por eso necesitamos una forma de atar los dos cambios.

Se hace todo, o no se hace nada

El método es sencillo. Se agrupan la resta y la suma en una sola unidad, y a esa unidad se la llama transacción. Todos los cambios que hay dentro se mantienen como provisionales.
Cuando todo está listo, la transacción se confirma y se aplica de verdad de una sola vez; si falla aunque sea una parte, se cancela entera. Confirmar se llama commit, y cancelar y deshacer se llama rollback. Así nunca existe un estado aplicado a medias, y nadie más ve el estado intermedio. Esta propiedad se llama atomicidad: la transacción es una unidad que no se puede dividir más.

Mete los dos cambios en un mismo paquete. Solo puedes confirmar cuando están los dos, y al cancelar desaparecen ambos.

Al confirmar, los dos saldos cambian juntos y el total queda igual; al cancelar, los dos cambios desaparecen limpiamente. En cualquier caso, las cuentas cuadran. Con solo tratar los cambios como un paquete, el hueco peligroso desapareció.
Pero ¿qué pasa si la luz se corta de verdad a mitad del trabajo dentro del paquete? ¿Qué ocurre con los cambios provisionales?

Aunque se corte, se revierte todo

Antes de cambiar nada, una base de datos anota primero qué va a cambiar y cómo en un registro llamado log. También guarda la información necesaria para volver al estado de antes de empezar.
Por eso, aunque la luz se corte a mitad de camino, cuando la base de datos vuelve a arrancar puede leer el log y encontrar los paquetes que no terminaron. En vez de dejar la mitad, revierte ese paquete por completo al estado de antes de empezar. En cambio, un paquete que ya se confirmó sobrevive intacto al corte de luz. Esta propiedad, que los resultados confirmados no se pierdan, se llama durabilidad.

Avanza un paso y luego toca el corte de luz. En vez de dejar la mitad, todo vuelve al estado inicial que se anotó aparte.

Se cortó la luz y, aun así, las cuentas están intactas. En lugar de un estado desordenado con solo la resta aplicada, todo volvió limpiamente al principio. Eso es un rollback.
Como un fallo no deja rastro, basta con empezar de nuevo desde el principio. Antes y después de la transferencia se respetan las reglas de las cuentas, como la de que el total de los dos saldos no cambia. A esto se le llama consistencia. Pero ¿qué pasa cuando varias personas intentan cambiar el mismo saldo al mismo tiempo?

Aunque lleguen a la vez, se atienden por turno

Recuerda la condición de carrera del área de sistemas operativos: cuando dos partes tocaban el mismo recurso a la vez, el resultado se enredaba. Con un saldo pasa lo mismo.
Si dos personas leen el mismo saldo en el mismo instante y cada una escribe el valor que calculó, la que escribe al final sobrescribe el resultado de la otra, y el cambio de una persona desaparece por completo. Esto se llama actualización perdida. Por eso, una base de datos usa mecanismos como los bloqueos para atender de uno en uno, por turno, los paquetes que cambian la misma fila.

Envía a las dos personas a la vez. Si lo dejas tal cual, la que escribe después sobrescribe y se pierde un cambio; si las atiendes por turno, se suman los dos.

Tal cual, se perdió el cambio de una persona; por turno, se aplicaron los dos. Aunque las peticiones lleguen juntas, esperan en fila un momento, y el siguiente paquete se atiende solo cuando el anterior terminó.
Esta propiedad, evitar que los paquetes que corren al mismo tiempo vean los estados intermedios de los demás, se llama aislamiento. Pero poner todo en fila de forma estricta vuelve las cosas lentas, así que las bases de datos reales dejan elegir con qué rigor se separan los paquetes.

Resumen

En resumen: los cambios que deben ocurrir juntos se agrupan en una sola unidad para que se hagan todos o ninguno. Si el trabajo se corta a mitad, la base de datos lee el log y revierte todo al principio, y los resultados confirmados sobreviven incluso a un corte de luz.
Cuando varios paquetes intentan cambiar el mismo lugar a la vez, se ponen en fila por turno para que nada se sobrescriba. Atomicidad, consistencia, aislamiento y durabilidad, conocidas por sus iniciales en inglés como ACID: estas cuatro promesas son una transacción.

Toca los puntos clave en orden para repasar. (una transferencia es una pareja → todo o nada → rollback ante un fallo → sin enredos a la vez)

Ahora conoces las promesas que permiten cambiar datos con seguridad. El hueco donde desaparecía el dinero, el accidente de un corte de luz que dejaba media transferencia, el lío de cambios simultáneos que se sobrescribían: la idea de un solo paquete protege de todo eso.
Después de cambiar datos con seguridad viene leerlos rápido. La próxima lección, sobre la caché, explica cómo tener una copia a mano en vez de ir una y otra vez hasta la base de datos por los mismos datos.