En las bases de datos, la eliminación lógica es aquella que ocurre al activar una marca de "eliminado" al registro, mientras que la eliminación física consiste en eliminar realmente el registro de la base. ¿Cuál estrategia es mejor?
Quienes aplican el borrado lógica sugieren agregar una columna "eliminado" a la tabla, y dejar los datos intactos. Una fila se considera borrada si la columna "eliminado" contiene un "true". Este enfoque es simple, facil de entender, rápido para implemente y explicar, pero a menudo se implementa mal. El problema es que, en general, eliminar una fila o entidad no es un evento simple. No sólo afecta a los datos del modelo, sino también a la forma del modelo. Es por esto que existen las claves foráneas, para asegurarnos de no terminar con Items de Factura sin una Factura padre. Y este es el más sencillo de los ejemplos...
Cuando hay que lidiar con las bajas lógicas, es facil terminar en situaciones de corrupción de datos. Por ejemplo, el campo "última órden" del Cliente (una optimización que nadie se acordó) podría terminar apuntando a una Orden con baja lógica.
Entonces, si un desarrollador tiene que borrar un registro de la base, y las bajas lógicas parecen desrecomendadas, queda la opción de las bajas físicas. Para preservar la integridad de datos, deberemos eliminar la fila en cuestión y todas las filas relacionadas en cascada. Pero en el mundo real la cascada no es posible.
Supongamos que el departamento de marketing decide eliminar un producto del catálogo. ¿Deberían desaparecer también todas las órdenes que contienen ese producto? Y si continuamos la cascada, ¿deberíamos borrar todas las peticiones para esas órdenes también? Y siguiendo, ¿deberíamos rearmar el resumen financiero de la empresa?
Obviamente, no.
El problema viene por la interpretación del "eliminar". En el ejemplo anterior, cuando marketing dice "eliminar", se refiere a discontinuar un producto. No queremos vender más este producto. Queremos quitarlo del inventario, y no hacer más pedidos a nuestro proveedor. El producto no debería aprecer más cuando nuestros clientes hacen una búsqueda en el sitio, pero la gente del almacen va a tener que seguir gestionando este producto en el interín. Por supuesto, es mucho más facil decir "eliminar el producto" que explicar todo esto.
Entonces, tenemos varias interpretaciones del "eliminar" para los usuarios:
- Las órdenes de compra no se borran: se cancelan. De hecho, también podría haber cargos extra por cancelar una órden tarde.
- Los empleados no se borran: renuncian, se jubilan o se los despide. También es probable que haya que gestionar una compensación.
- Los puestos no se borran: se cubren (cuando entra un candidato).
- y así...
En todos los casos, debemos enfocarnos en la tarea que el usuario desea realizar, en vez de en acciones técnicas sobre la base de datos.
En vez de enfocarnos en una columna "eliminado", lo mejor es usar un campo que contenga el estado del dato: activo, discontinuado, cancelado, obsoleto, etc. Estos campos de estado le permiten al usuario mirar los datos históricos y tomar decisiones.
La eliminacion física de datos puede tener consecuencias negativas más allá de romper la integridad. Tenemos que tener mucho cuidado cuando intentamos una eliminación física. Y como regla general, no borremos nada.
