Cita:
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.