Diferencias entre usar o no Transacciones

[[kuan-yiu]]

Las transacciones son la forma más sencilla de encadenar operaciones sobre la BD que no se puedan hacer de forma independiente.
Si yo tengo que ejecutar A,B y C siempre en ese orden y siempre todas o ninguna es mucho más sencillo, claro y mantenible meterlas en una transacción que mediante if-else revisar si todo ha ido bien, si puedo continuar... Yo lo veo como una forma de ahorrar comprobaciones.

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

Empezado por kuan-yiu

...y siempre todas o ninguna

Yo creo que esa es la clave.

Adicionalmente te pueden servir utilizando diferentes "Isolation Level" para resolver algunos problemas de bloqueos entre los usuarios.
Es un tema que ya hemos discutido otras veces, y recuerdo uno de los últimos hilos que estaba muy interesante.

[MaMu]

Empezado por Neftali

Yo creo que esa es la clave.

Adicionalmente te pueden servir utilizando diferentes "Isolation Level" para resolver algunos problemas de bloqueos entre los usuarios.
Es un tema que ya hemos discutido otras veces, y recuerdo uno de los últimos hilos que estaba muy interesante.

Claro, en el caso mi aplicación, nunca puede porducirse que dos o mas usuarios modifiquen un registro al mismo tiempo. Pero estoy por desarrollar una en la que posiblemente, sean varios usuarios quienes posiblemente intenten editar un registro al mismo tiempo.

[[kuan-yiu]]

Entonces no te la jueges. Puede que al final nunca tengas accesos concurrentes pero lo mejor es programar como si los hubiese.

[cascarrabias]

Lo que te comentan los companieros es muy cierto...el punto esencial de una transaccion es que engloba multiples operaciones en un solo paso(todo o nada).

Tampoco debes olvidar, no solo hablando de muchos usuario, incluso pensando en uno solo haciendo una insercion de registros en digamos 3 tablas si por hazares del destino ocurre una falla en la insercion de una de las tablas (porque hasta errores improbables sucede) y solo lograste hacer la insercion en 2 y en la tercera no...ya vas a tener informacion inconsistente... te dejo este ejemplo muy sencillo pero util.....

Considere la base de datos de un banco que contiene balances para varias cuentas de clientes, supongamos que queremos registrar el pago de $100 desde la cuenta de Alice hacia la cuenta de Bob, las sentencias SQL a ejecutar para esta operacion serian como la siguiente:

Código SQL [-]
UPDATE cuentas SET balance = balance - 100 WHERE nombre = ‘Alice’;
UPDATE branches SET balance = balance - 100 WHERE nombre = (SELECT branch_name FROM cuentas WHERE nombre = ‘Alice’);
UPDATE cuentas SET balance = balance + 100 WHERE nombre = ‘Bob’;
UPDATE branches SET balance = balance + 100 WHERE nombre = (SELECT branch_name FROM cuentas WHERE nombre = ‘Bob’);

Como se puede observar hay varias actualizaciones involucradas para terminar la operacion, los operadores del banco deben estar seguros de que todas esas actualizaciones se ejecuten, o en caso de falla que ninguna se ejecute, ya que se podria dar el caso de que Bob reciba $100 sin que sean debitados de la cuenta de Alice. Agrupando las actualizaciones en una sola transaccion se puede garantizar que en caso de un fallo ninguna actualizacion se ejecute.

[MaMu]

Los ejemplos de roman y cascarrabias me han sido muy utiles para apreciar el objeto de una transacción.
Ahora bien,

1) Cuándo debo iniciar la transacción?
2) Cómo debe finalizar?
3) Es el engine quien se encarga de negociar la conciliación de datos?
4) Si tengo un error, utilizo RollBack, pero como se cuando es exitosa?

Saludos

[[maeyanes]]

Hola...

Te contesto de acuerdo a mi experiencia:

Empezado por MaMu

1) Cuándo debo iniciar la transacción?

Una transacción la debes iniciar justo antes de mandar los datos a la base de datos:

Código Delphi [-]
Transaction1.StartTransaction;
DataSet1.Post;
DataSet2.Post;

2) Cómo debe finalizar?

Mayormente con Commit o Rollback, esto de acuerdo al resultado de las operaciones...

3) Es el engine quien se encarga de negociar la conciliación de datos?

Si te refieres a la integridad de los datos, mayormente se verifican en la parte del servidor mediante reglas de integridad referencial, disparadores y procedimientos almacenados.

Si alguna de estas operaciones de verificador terminan en un error, el servidor se encarga de comunicar al cliente de tal situación...

4) Si tengo un error, utilizo RollBack, pero como se cuando es exitosa?

Saludos

Usando la captura de excepciones:

Código Delphi [-]
Transaction.StartTransaction;
try
  DataSet1.Post;
  DataSet2.Post;
  Transaction.Commit
except
  Transaction.Rollback;
  ShowMessage('Ocurrió un error')
end

Espero que te aclare un poco tus dudas...


Saludos...

[[AzidRain]]

Las transacciones no necesariamente son útiles solo para manejar concurrencia. Son útiles cuando necesitas ejecutar varias instrucciones para llevar a cabo una tarea. Por ejemplo:

1.- Insertar un registro en la tabla de facturas
2.- Insertar un registro por cada linea de detalle de la factura
3.- Insertar un registro correspondinete a la factura pero en la tabla de cuentas cobrables.

Supongamos que esto lo hacemos sin transacciones y se presenta un error (cualquiera) al momento de ejecutar 2 o 3. Es obvio que tendríamos que deshacer los cambios realizados en los pasos anteriores. Con las transacciones esto se resuleve sencillamente metiendo todo lo que pueda fallar en un try..except y ejecutando un rollback si hay error, de manera que si algo falla no se modifica nada de las tablas.

Un apunte, en el caso de MySQL si utilizas una tabla con campos autoincrementables al solicitar un número en una tabla dentro de una transaccion el campo se incrementa normalmente para cuando se requiera otro número, pero si la transacción se aborta con un rollback ese número autogenerado ya no se recupera en la tabla por lo que quedan huecos en la secuencia.

Por ejemplo:

1- Abrimos la transaccion.
2. Abrimos la tabla facturas que tiene un campo folio tipo autoinc que en este caso va a valer 1.
3.- Guardamos nuestros datos.
4.- Fializamos la transacción.

Ahora abrimos otra transaccion.
Solicitamos un nuevo folio (nos devuelve 2)
Ocurre un error y hacemos rollback.

Abrimos una nueva transaccion.
Solicitamos un nuevo folio...y nos devuelve 3!!

En este caso el 2 se perdió en la transacción abortada aunque no afecta por que no hay forma de que otra transacción obtenga exactamente el mismo número.

[Casimiro Noteví]

Lo que comentas sobre los campos autoincrementales es el método habitual de funcionamiento en la mayoría de bases de datos.
Para llevar un control de números "sin huecos" es necesario usar otras técnicas.

[danilo_candales]

Quizas no es la definición mas completa, pero puede dar una idea bastante clara de que significa una transaccion y sus principales caracterisicas.

http://es.wikipedia.org/wiki/ACID

Saludos,

[[Delphius]]

No estaría demás aclarar algo que ya fue dicho implícitamente: estructurar las tablas y emplear las transacciones de la manera más simple posible.

Si bien lo "simple" es un término subjetivo... por lo general significa:
1. Ser lo más breve posible, y (o bien)
2. Que involucre la menor cantidad de tablas y/o registros posibles para llevar a cabo la consistencia de información.

No es lo mismo llevar una transacción de 30 registros en 5 tablas que llevar una transacción de 5 registros en 30 tablas.

Como también no es lo mismo llevar abierta una transacción durante media hora en un negocio de poco movimiento para atender a 5 clientes durante todo el día, que llevar un negocio de todo 24 hrs en donde en esas 24 hrs se atienden a cientos o miles de personas.

El ejemplo de Roman y el de cascarrabias me hicieron acordar que hace unos días tuve que ir al banco a pagar los impuestos mensuales, como lo ha hecho ese mismo día muchas de las otras personas que he visto en cola. La cuestión es que estuve una hora parado para ser atendido, la cola era larga (unas 20 personas antes que yo). Veamos el escenario:
Cajero: Femenino
Edad aproximada: 50 años
Tiempo promedio de servicio: 6 minutos

Llevaba media hora y la gente impaciente se empezó a ir... unas 3 o 4 he contado. Un poco de matemática: a 6 min por persona durante media hora son 5 personas. Más el peor caso de desertores (3) nos da 20 - 8 = 12.
una vez atendida la quinta persona, la cajera se fue (vaya a saber porqué) y se sentó un señor.
Edad aproximadada: 40 años
Tiempo promedio de servicio: incalculable, simplemente rápido.

La cuestión es que esta cajera se demoró media hora en atender a 5, pero esta otra persona atendió a 13 personas en esa media hora restante (yo incluído).

Dos preguntas:
¿Aplicarías transacciones en este esquema?
Si tu respuesta es un si ¿Cuando iniciarías la transacción? ¿Ni bien llega el cajero?.... Si atiende esta cajera e iniciamos la transacción ni bien se acerca el cliente tendríamos la transacción abierta durante 6 minutos. Si lo hacemos con el cajero... ¡pues saquemos cuentas!

En otros escenarios, o modelos tal vez la situación es diferente: emplear transacciones es una pérdida de tiempo porque simplemente no se llevan en práctica. Ya sea porque la probabilidad de un acceso recurrente es muy baja (1) o porque simplemente la propia naturaleza del negocio demuestra que no hay motivos de acceso recurrente (algo raro pero quien sabe... en alguna de esas existe).

Lo cierto es que el tema de las transacciones puede requerir de un análisis de un día como de una hora.

(1) Por ejemplo ahora se me ocurre la situación de la mueblería que esta cerca de casa: Por lo general sus empleados están ociosos y el estar en una calle sin salida, media oculta y con poco tráfico hace que la demanda de clientela sea muy baja.
No todos los días la gente compra y repara muebles y por lo general se trata de un negocio que no tiene demasiado movimiento. Siendo honesto, con suerte ese negocio debe ser visitado cuanto mucho 3 o 4 veces al día, no he visto gente allí (no me extraña que esté casi en quiebra).

Y una pregunta boba, ¿conlleva alguna utilidad realizar transacciones cuando se trata de una aplicación monousuario?

A lo que voy es que aplicar transacciones es útil cuando se demuestra que existe una probabilidad mediana de un acceso y uso recurrente.

Esto de las probabilidades me gusta... el ejemplo que se ha puesto aquí con lo dicho por Ian Marteens me hace acordar sobre preguntas filosóficas: ¿Que tan probable es que Pepito desee sacar dinero de su cuenta y que al mismo instante de tiempo Juancito le está haciendo un depósito? ¿Y si se trata de que Pepito realiza una consulta de saldo? ¿Se puede? ¿Y que sucede?

No me hagan caso... es que ando medio enojado todavia con aquella cajera por no atender rápido. ¡Que lo tiró!

Saludos sin transacciones: este mensaje fue escrito en 40 minutos!