Diferencias entre usar o no Transacciones

[[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 Notevi]

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!

[[Lepe]]

La probabilidad de desaguisados, incluso en monousuario, es alto (lo que decía AzidRain). Si se puede, mejor usar transacciones.

Lo peor si cabe, es aprender a usarlas, después intuitivamente se implementa.

Saludos

[Casimiro Notevi]

Por supuesto, hay que usar transacciones siempre.
Siempre que exista peligra de provocar incoherencias con los datos.
No se trata solamente de la concurrencia multiusuario, no es eso, se trata de mantener siempre la coherencia de los datos, me explico con la tienda de muebles que hay junto a la casa de Delphius:
Delphius está cansado de la silla que usa para trabajar con su ordenador, está ya muy vieja, el asiento es durísimo y no puede aguantar más de 10 minutos seguidos sin tener que ponerse de pié a descansar sus posaderas, así que un día se dice: "¡se acabó!", le da una patada y la rompe, abre su hucha y saca todos sus ahorros, cree que le alcanza para una nueva. Agarra la silla rota, sale a la calle, la deja junto al contenedor de la basura y se mete en la tienda de muebles.
No tiene que esperar cola porque no hay nadie más a quien atender, ve una silla que le encanta, la prueba, es supercómoda además de bonita y no muy cara, le alcanza con sus ahorros, así que decide llevársela.
El dependiente de la tienda anota la venta en su obsoleto ordenador mientras le explica a Delphius que ha tenido suerte, que es la única silla que le quedaba de ese modelo y que ya no traerá más porque no se fabrica.

Nueva factura >> artículo: "Silla especial para programadores" >> cantidad: 1 >> precio: 30$ >> "aceptar"...
El viejo ordenador, un IBM PC con un intel 8088 a 4 Mhz, 640 Kb de ram, (nunca nadie necesitará más) comienza a ronronear su disco de 20 Megas. En la pantalla fósforo verde se puede leer:

>Creando factura... creada.
>Anotando importe en caja... anotado.
>Actualizando inventario... ¡¡¡ Pluuufff !!!, se ha ido la luz.

El "¡¡¡ Pluuufff !!!, se ha ido la luz." no lo ponía en la pantalla, es lo que sucedió. Vaya contrariedad.

Mientras espera que vuelva la luz, Delphius le explica al dependiente que si tuviera un SAI (UPS) hubiera podido acabar de hacer la factura y luego haber apagado el ordenador sin peligro.
Ante la tardanza, Delphius, mientras tanto, se entretiene mirando una mesa con soporte retráctil para el teclado, el precio le asusta, tendrá que ahorrar bastante tiempo, de momento deberá conformarse con la silla únicamente.
Por fin, ya vuelve la luz, el dependiente enciende el ordenador y hace una verificación de los datos que presenta en pantalla:

Ventas del día
-----------------------------------
Factura nº : 234
Referencia : SILLA001
Descripción: Silla para programador
Cantidad...: 1
Precio.....: 30$


Arqueo de caja
---------------
Caja nº ..: 1
Factura nº: 234
Importe ..: 30$
Total caja: 30$


Inventario artículos
------------------------------------
Referencia..: SILLA001
Descripción : Silla para programador
Stock actual: 1

Aquí vemos que hay una inconsistencia en la base de datos, (además de que indica que debe existir 30$ que no ha cobrado todavía) dice que ha vendido la silla que quedaba y, sin embargo, también dice que hay una silla en el stock.
Delphius le explica al dependiente que eso le ha ocurrido porque el programa de ventas que está usando, de la empresa moco$oft es bastante malo y no usa transacciones, el dependiente lo escucha pero no lo oye, está pensado en cómo arreglar el problema antes de que llegue el dueño de la tienda y le eche la culpa a él de no saber usar el ordenador y de haberse apropiado de 30$ que realmente no ha cobrado todavía.
Delphius, que además de ser una buena persona es un afamado programador se ofrece a ayudar al pobre tipo y usando técnicas de hacker, un programa descompilador, un depurador de ensamblador y un conjuro que le enseñó un chamán amigo de su tía Hermenegilda... finalmente consigue añadirle transacciones al programa (es que este Delphius es tremendo) y lo deja así:

var
__iNumFactura:integer;
begin
__try
____StartTransaction;
____iNumFactura := HacerFacturaNueva(now); // crea la factura
____CobrarFactura( iNumFactura ); // hace el apunte en caja
____DescontarInventario( iNumFactura ); // descuenta el artículo del inventario de artículos
____Post;
____Commit;
__except
____Rollback;
__end;
end;

El dueño de la tienda, en agradecimiento, contrató a Delphius para hacer una nueva gestión comercial para su cadena de tiendas por todo el país, tendría que conectar en tiempo real decenas de tiendas, él sería el jefe del departamento de informática, tendría a su cargo una gran cantidad de programadores y... bueno, eso es otra historia.


Moraleja: usa transacciones si no quieres quedarte sin silla

[[Delphius]]

Amigo Casi, me encantó la historia.
Me he reído bastante

Creo que con ello completas y das a entender el uso de las transacciones. Yo andaba buscando la manera de darle un aspecto un tantito irónico a mi cuento de la vida real. Me quedo con tu historia

Saludos,
PD: Por cierto, la silla que uso si bien es un tanto viejita es muy cómoda. Aunque admito que de vez en cuando me reclino y pongo los pies sobre el escritorio.

[[AzidRain]]

Mi buen Delphius ya lo acaba de decir el buen Casi...

Las transacciones, fuera de lo que se podría pensar, fueron diseñadas para mantener a toda costa la integridad de los datos no tanto para la concurrencia. Digamos que esto fue un efecto adicional.

Ahora respecto a tus dudas...

En el caso del POS que ejemplificas:

1.- Una transacción solo comienza cuando:
El operador (cajero) escanea o digita un producto desde que se terminó la última transacción.
2.- Una transacción solo termina cuando:
El operador entrega el cambio al cliente (previo cálculo del sistema)

En los sistemas de POS además de todo ello hay que considerar que el operador debe ser capaz de seguir cobrando (como sea) aun y cuando no tenga comunicación con el servidor (ah verdad) y ahi es donde viene el chiste del asunto de los POS.

El enfoque de IBM en su ya viejo SO especial para POS prácticamente es un estandar mundial ya que es muy confiable y evita este tipo de problemas (aun y cuando los displays no se ven bonitos ni nada de esas jaladas que muchos nos inventamos). Ese sistema es ROBUSTO con mayúsculas ya que prácticamente tienes que destruir todo para que no haya forma de recuperarse de algún problema. Y el enfoque que usaron ellos: simple....KISS