Ciclo de vida del dato, estado y operaciones

¿Por qué permitir «editar o borrar cualquier registro» suele ser un error grave en un sistema de reservas o de facturación? En muchos tutoriales iniciales se enseña que gestionar datos consiste simplemente en crear, leer, editar y borrar filas a voluntad. Sin embargo, en un sistema real, no todos los cambios son válidos ni todos los datos pueden desaparecer sin dejar rastro.

Objetivos y conocimientos previos

A partir de Estructuras y relaciones, aprenderás qué son las cuatro operaciones básicas de mantenimiento de datos (CRUD / ABC), cómo gobernarlas mediante máquinas de estados y transiciones válidas, y cuándo debes prohibir la sobrescritura o el borrado físico para preservar la auditoría del sistema.

Las cuatro operaciones básicas (CRUD o ABC)

Tradicionalmente, las operaciones sobre una colección de datos se resumen con las siglas en inglés CRUD (Create, Read, Update, Delete) o ABC en español (Altas, Bajas, Cambios y Consultas):

Pedir a un agente «créame un CRUD de facturas» sin más especificaciones es peligroso: por defecto, el agente generará cuatro operaciones sin restricciones que permitirán cambiar el importe de una factura ya pagada o borrar la factura número 102 dejando un hueco inexplicable en la numeración.

De la edición libre a las transiciones de estado

En lugar de permitir que cualquier campo se modifique en cualquier momento, los sistemas fiables modelan el ciclo de vida de una entidad como un conjunto de estados válidos y transiciones permitidas.

Observa las reglas de transición para una factura:

Podemos expresar estas reglas con exactitud en una tabla de transiciones de estado:

Baja física frente a baja lógica y movimientos compensatorios

Cuando alguien pide «dar de baja» un registro, debes distinguir tres mecanismos muy diferentes:

1. Baja física (Borrado destructivo): El registro se destruye del almacenamiento como si jamás hubiera existido. Solo es aceptable para datos transitorios sin valor histórico (como un borrador temporal no emitido) o cuando la ley exige eliminar datos personales bajo condiciones específicas.
2. Baja lógica (Cambio de estado o desactivación): El registro se conserva íntegro, pero su estado cambia a CANCELADA, ANULADA o INACTIVO. Así, una reserva cancelada libera su plaza (porque solo las reservas en estado ACTIVA ocupan aforo), pero el sistema conserva la evidencia de quién reservó y cuándo canceló.
3. Movimiento compensatorio (Inmutabilidad contable): En sistemas financieros o de inventario, los movimientos confirmados nunca se editan ni se borran. Si se cobraron 100 EUR por error, no se borra el cobro: se registra un segundo movimiento de -100 EUR (reembolso) vinculado al primero. De ese modo, el saldo final es 0 EUR, pero la historia completa de lo ocurrido permanece auditable.

Datos derivados frente a datos almacenados

En una consulta o informe aparecen valores como el total gastado en el mes o las plazas disponibles en una actividad.

Debes decidir si ese valor se calcula a partir de los registros fuente o si se guarda en un campo adicional:

• Si la capacidad es 10 y hay 7 reservas en estado ACTIVA, las plazas disponibles (3) son un dato derivado de esos dos hechos.
• Si además guardas un campo suelto plazas_disponibles = 3 y por un error un proceso cancela una reserva sin actualizar ese contador, el sistema entrará en contradicción consigo mismo: dirá que quedan 3 plazas cuando solo hay 6 reservas activas.

Siempre que sea posible, define una única fuente de verdad para cada hecho y verifica que cualquier resumen o contador acumulado permanezca sincronizado con los movimientos que lo justifican.

Practica

Vuelve al caso de las Reservas de una actividad del Curso I y combínalo con lo aprendido sobre ciclo de vida de los datos. Un agente te dice: «Para simplificar, cuando una persona cancela su reserva ejecuto un DELETE (borrado físico) de su fila en la tabla de reservas. Así siempre sé cuántas plazas ocupadas hay contando las filas que quedan».

1. Explica qué ventaja aparente vio el agente en esa decisión.
2. Identifica tres problemas reales que provoca borrar físicamente la reserva cuando una persona reclama: «Yo tenía una reserva confirmada ayer y hoy el sistema dice que nunca reservé» o cuando la persona reintenta cancelar dos veces seguidas.
3. Diseña la alternativa usando baja lógica: qué estados puede tener una reserva, cómo se calcula el aforo ocupado y qué responde el sistema ante la primera y la segunda solicitud de cancelación de la misma reserva.

Criterio de comprensión: debes explicar por qué el borrado físico destruye la trazabilidad y hace indistinguible una «reserva que fue cancelada» de una «reserva que jamás existió», y especificar cómo la consulta de plazas ocupadas debe filtrar únicamente las reservas con estado ACTIVA.

Profundiza con IA

Esta es mi respuesta sobre por qué usar baja lógica y estados en lugar de borrado físico en las reservas: [tu respuesta]. Ponme a prueba con un caso nuevo: si una persona cancela su reserva activa y cinco minutos después quiere volver a reservar plaza en la misma actividad, ¿debería reactivar el registro anterior o crear un nuevo movimiento? Ayúdame a comparar los pros y contras de ambas opciones sin decidir por mí.

Siguiente lectura

Incluso con un modelo de datos bien relacionado y una tabla de estados impecable, ¿qué pasa si el sistema se apaga a mitad de un cambio o si dos personas modifican el mismo estado a la vez? Cerramos el curso con Persistencia, transacciones y concurrencia.