Era un día normal en la oficina cuando surgió el clásico incidente: un cliente borró por error algunos registros desde la interfaz y la pregunta inevitable llegó rápidamente puedo recuperarlos. Restaurar desde backup era la respuesta técnica pero poco práctica para un solo registro. La alternativa elegante es implementar eliminaciones suaves o soft deletes, una técnica que marca registros como borrados sin expulsarlos físicamente de la base de datos.
Qué es una eliminacion suave y por qué importa Las eliminaciones suaves consisten en añadir una columna identificadora, por ejemplo deleted_at de tipo datetime nula, que indica si el registro esta activo o ha sido marcado como eliminado. La aplicación filtra automáticamente los registros donde deleted_at es distinto de null para que los usuarios no los vean. Beneficios principales recuperacion de datos por errores humanos, trazabilidad para auditoria y estabilidad en las relaciones entre tablas sin romper integridad aparente.
Diseño basico en Prisma En Prisma lo habitual es añadir en tus modelos un campo deleted_at DateTime? y luego asegurar que todas las consultas por defecto excluyan filas donde deleted_at no es null. Esto se puede lograr sin repetir condiciones where en todo el codigo ampliando el cliente de Prisma con extensiones que intercepten consultas comunes como findUnique findFirst findMany update y delete y apliquen la condicion deleted_at null de forma transparente.
Extender Prisma client para soft deletes En vez de dispersar checks por el servicio o controlador conviene encapsular la logica en una extension del cliente de Prisma. La extension puede interceptar consultas y eliminar el campo deleted_at de los resultados salvo que el desarrollador pida expresamente incluir registros borrados. Tambien es el lugar ideal para añadir metodos utiles restore y hardDelete que simplifican operaciones concretas y evitan repetir patrones peligrosos en el resto de la aplicacion.
Comportamiento recomendado del metodo delete En un entorno con eliminaciones suaves el metodo que antes borraba fisicamente debe marcar deleted_at con la fecha actual. Si se necesita purgar datos existe un metodo hardDelete que ejecuta la eliminacion fisica. Importante distinguir entre llamadas que solicitan hard delete y las que aplican el comportamiento por defecto soft delete.
Rescatar registros borrados Con una extension adecuada restaurar un elemento es simplemente actualizar deleted_at a null usando un helper restore. Asimismo se pueden crear helpers para consultar incluyendo los registros borrados por ejemplo findFirstWithDeleted util para paneles de administracion o auditoria.
Manejo de relaciones y efectos colaterales El verdadero reto de las eliminaciones suaves aparece con relaciones. Si se borra un usuario hay que decidir que pasa con sus publicaciones comentarios y entidades dependientes. Lo habitual es aplicar un borrado suave en cascada marcando deleted_at en los hijos que esten activos y usar transacciones para garantizar consistencia. El problema mas sutil surge cuando un hijo ya estaba eliminado antes del borrado del padre al restaurar el padre no siempre conviene restaurar esos hijos que fueron eliminados voluntariamente. Para evitar resucitar registros que debian permanecer borrados hay que mantener metadatos adicionales o reglas que distingan borrados manuales de borrados por cascada.
Transacciones y extensiones de Prisma Un punto donde muchos desarrolladores tropiezan es el uso de transacciones con prisma. El objeto transaction es distinto del cliente global y dentro del bloque de transaccion no estan disponibles las extensiones añadidas al cliente global. La recomendacion es contener toda la logica compleja de borrado y restauracion dentro de la transaccion y usar exclusivamente el cliente de transaccion alli para que todas las operaciones formen parte del mismo commit.
Proteger deleted_at en creaciones y actualizaciones Una regla practica vital es no permitir que codigo ordinario modifique deleted_at en operaciones create o update. Esa columna debe ser gestionada solo por la extension o capa de servicio que implemente la politica de borrado. Si cualquier endpoint de la API puede tocar deleted_at la aplicacion quedara expuesta a desapariciones accidentales de registros.
Unicidad y registros fantasma Las restricciones unique como email pueden chocar con las filas suaves porque la base de datos sigue viendo el valor. Soluciones posibles crear indices unicos parciales que apliquen solo cuando deleted_at es null si la base de datos lo soporta renombrar o anadir sufijos a campos unicos al marcar como borrados para liberar valores originales o implementar comprobaciones a nivel de aplicacion que ignoren registros borrados. Cada opcion tiene ventajas e inconvenientes por simplicidad mantenimiento y portabilidad.
Rendimiento e indices Cuando la tabla crece las filas marcadas como borradas continúan existiendo y las consultas WHERE deleted_at IS NULL pueden volverse costosas. Lo correcto es añadir un indice sobre deleted_at y si se realizan consultas combinadas crear indices compuestos por ejemplo por authorId y deleted_at para acelerar filtros comunes. Indices adecuados mantienen el rendimiento y reducen coste de infraestructura.
Contar agrupar y agregar recuerde que metodos como count aggregate y groupBy no aplican automaticamente filtros de borrado. Si no se añade where deleted_at null los informes y paneles reportaran filas fantasma. Lo ideal es encapsular esa logica de filtrado en la extension del cliente para que los agregados reflejen la realidad vista por los usuarios.
Buenas practicas resumen Mantener coherencia entre borrados blandos y duros y documentar la estrategia aplicar la regla de solo la extension toca deleted_at usar transacciones para operaciones en cascada indexar deleted_at y campos compuestos para consultas frecuentes y pensar en la gestion de unicidad para no bloquear nuevos usuarios o entidades por registros borrados.
Como puede ayudar Q2BSTUDIO En Q2BSTUDIO somos una empresa de desarrollo de software que crea aplicaciones a medida y soluciones de software a medida pensadas para la escalabilidad y la seguridad. Si quiere que su proyecto incorpore patrones robustos como eliminaciones suaves bien integradas con practicas de seguridad y buenas practicas de desarrollo podemos ayudarle. Ofrecemos servicios en inteligencia artificial ia para empresas agentes IA y consultoria para integrar modelos en su aplicacion ademas de servicios cloud aws y azure y expertos en ciberseguridad que garantizan la integridad de sus datos. Para proyectos de desarrollo consulte nuestro servicio de desarrollo de aplicaciones y software a medida y para soluciones de IA visite nuestra pagina de servicios de inteligencia artificial para empresas.
Palabras clave relevantes aplicadas en este articulo aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws y azure servicios inteligencia de negocio ia para empresas agentes IA power bi sirven para mejorar posicionamiento y reflejan las capacidades que ofrecemos en proyectos que integran patrones de persistencia avanzados como soft deletes.
Si desea un ejemplo practico o que revisemos su esquema de datos y le propongamos una extension de Prisma personalizada en Q2BSTUDIO podemos acompañarle desde el diseno hasta la puesta en produccion incluyendo pruebas de seguridad pentesting y cuadros de mando con Power BI para que sus analiticas no esten contaminadas por registros fantasma.
Gracias por leer si tiene dudas o quiere que le ayudemos a implementar esta estrategia contacte con nuestro equipo y le guiaremos en la mejor solucion tecnica y de negocio para su producto digital.