¿Cuándo usar transacciones?

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Imagina que estás sacando un informe de balance contable y mientras está la impresora ocupada, alguien añade/elimina/edita algún registro, te volverás loco para encontrar el fallo, deberás revisar todos los registros uno por uno para encontrar el "error" de cálculo, que no es ningún error.

No acabo de entender cual es el problema en la situación que comentas Casimiro.

Dejando de lado el motor y los componentes de acceso, creo que todos estamos de acuerdo en lo siguiente (si no, vamos a intentar concretarlo para saber de qué hablamos):

* Una transacción BLOQUEA la/s tabla/s que usa para escritura. Nadie puede escribir en esas tablas mientras la tabla está en uso.
* Todas las operaciones de una transacción se ejecutan de forma atómica.
* Al ser atómica y bloqueante, una transacción debe ser lo más rápida y pequeña posible.

Volvendo a lo comentado por Casimiro, yo creo que los SELECT no deben ir con transacciones (vuelvo a decir, independientemente de los que luego haga un SGBD o unos componente), porque no cumple nada de lo anterior:

+ Un SELECT (uno normal, al menos) no debe bloquear para escritura.
+ Un SELECT ya es de por sí, una operación atómica, unitaria.
+ Un SELECT no es precísamente (o no tiene porqué serlo) una operación rápida.

Otra cosa, y creo que por ahí nos estamos liando, es que un determinado proceso de SELECT (1 o varios), requiera que una determinada tabla (o varias) no se modifique/n, y eso podamos "corregirlo" o "solucionarlo" con una transacción, pero creo que no es el caso habitual.
Recordar también que una transación "añade" sobrecarga a una operación (más recursos, más tiempo, más proceso), por lo tanto, por definición, sólo debería usarse cuando sea estríctamente necesario.