Imagine que transfiere 200.000 euros de una cuenta bancaria a otra. Retiras el importe de la cuenta de origen y luego lo depositas en la cuenta de destino. Hasta aquí todo es normal y en un mundo perfecto la operación tendría éxito. Por desgracia, en el mundo real las cosas pueden salir mal. Algo sucede y el dinero se pierde. Eso es muy malo.
Pues bien, ¡las transacciones están aquí para garantizar que esto no ocurra con sus aplicaciones! En esta entrada del blog exploraremos en detalle el uso y la importancia de las transacciones, así como varios escenarios que muestran cómo pueden salvar tu negocio.
¿Qué son las transacciones?
Según la documentación
Las transacciones son una serie de modificaciones de datos relacionadas que se realizan en una base de datos dentro de un proceso. Una transacción no se guarda en una base de datos de forma permanente hasta que se valida la transacción. Si una transacción no se completa, ya sea porque se cancela o por algún evento externo, las modificaciones no se guardan.
Es importante tener en cuenta:
Cuando se utilizan transacciones anidadas, el resultado de cada subtransacción depende de la validación o cancelación de la transacción de nivel superior. Si la transacción de nivel superior se valida, los resultados de las subtransacciones se confirman (validación o cancelación). Por otro lado, si la transacción de nivel superior se cancela, todas las subtransacciones se cancelan, independientemente de sus respectivos resultados.
Asegúrese de consultar la documentación para obtener información más detallada sobre las transacciones.
Uso de las transacciones
Es difícil imaginar aplicaciones empresariales que no utilicen transacciones, ¡pero de vez en cuando las he visto! Al hablar de esta falta de transacciones con los desarrolladores de la aplicación, he escuchado frases como «oh, hasta ahora ha funcionado», o incluso «siempre hemos tenido suerte». En mi opinión, la suerte no debería ser un concepto de diseño para las aplicaciones empresariales.
Un ejemplo clásico de uso de transacciones es la contabilidad. Los estados financieros proporcionan un registro de dos categorías: activos y pasivos. Ambos deben calcularse y guardarse (completamente, nunca parcialmente), o no tocarse en absoluto.
Otro ejemplo es un sistema de envío, en el que la creación de un pedido disminuye el inventario en el almacén. En lugar de confiar en la suerte, hay que asegurarse de que tanto el pedido como los registros de inventario se crean o modifican juntos. Pase lo que pase, ambas operaciones se completan o se cancelan.
Se puede pensar en una transacción como una especie de gran corchete:
- Si la abre (START TRANSACTION comando),
- realizar operaciones en la base de datos (crear/modificar/borrar registros – de una o varias tablas),
- luego se cierra validando (VALIDATE TRANSACTION comando) o cancelando (CANCEL TRANSACTION command) TODAS las operaciones.
Además de las operaciones de bajo nivel en la base de datos, otro buen caso para hacer uso de las transacciones es una interfaz de usuario. Imagina un formulario de entrada de facturas, utilizando un cuadro de lista (o subformulario) con artículos de productos (almacenados en otra tabla) … o clientes y contactos … o contactos y números de teléfono. La lista sigue y sigue ….
Su usuario quiere modificar una factura. Es posible que cambie uno o varios elementos, y que finalmente decida hacer clic en el botón de cancelar y asumir que todas las modificaciones de elementos de la factura se revierten (no se guardan). Podrías manejar esto con matrices complejas o simplemente usando una transacción.
Con suerte, usted ya está usando transacciones.
Usando Transacciones Anidadas
Escenario uno: una aplicación de Contacto
Digamos que tiene una estructura simple con 2 tablas: clientes y contactos. Tiene un formulario de entrada de clientes que incluye un cuadro de lista de registros de contactos. Al hacer doble clic en un registro, se abre un formulario de entrada de contactos con más detalles del contacto.
Esto es lo que puede ocurrir:
- Un usuario final abre un registro de cliente y modifica el nombre de la calle.
- A continuación, abre el contacto «A», modifica la fecha de nacimiento y cierra el formulario de contacto haciendo clic en el botón OK.
- A continuación, abre el contacto «B», modifica algo y decide cancelar los cambios.
- De vuelta al formulario del cliente, el usuario final hace clic en el botón OK para completar sus actividades.
El usuario espera que su modificación del contacto «A» se guarde, mientras que la modificación del contacto «B» no. Por supuesto, los cambios en el registro del cliente también deberían guardarse.
Con las transacciones anidadas, esto es fácil de manejar. Basta con utilizar una transacción en el formulario del cliente, y otra transacción en el formulario del contacto. No hay que preocuparse.
Segundo escenario: procesamiento automático por lotes
Un escenario completamente diferente – pero con el mismo concepto – es el procesamiento automático por lotes (cálculos, importación, etc.):
- En medio de un trabajo por lotes complejo, necesita detener el proceso por alguna razón(por ejemplo, si se encuentran datos erróneos o un usuario solicita cancelar/abandonar).
Con una transacción de un solo nivel, sólo puede cancelar todas las operaciones, o detenerse en medio, lo que da lugar a una situación poco clara. Usted puede estar pensando «Yo no me detendría en el medio, terminaría la operación antes de detenerme». Eso está muy bien, pero ¿cómo manejarías los cortes de energía, las caídas, los fallos de hardware y otros errores inesperados?
Ya que no puedes… y contar con la suerte no es fiable… el sistema debería estar diseñado para garantizar la fiabilidad de los datos.
Hay que tener en cuenta…
Las transacciones le permiten controlar este tipo de situaciones. Utilice transacciones individuales para cada operación (importación de datos, realización de cálculos, etc.) anidadas dentro de una transacción de nivel superior (para permitir cancelar o validar todas las operaciones).
Si una transacción no se completa por cualquier motivo (caída, corte de energía, etc.), ¡no hay que temer! Todas las operaciones ya realizadas se deshacen porque la transacción de nivel superior aún no ha validado nada.