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!