No eliminar creará una nueva clase de errores para todas las consultas futuras. No olvide que la escritura de consultas a menudo la realizan usuarios avanzados (es decir, no profesionales de TI) y desarrolladores junior. Así que ahora cada tabla que tenga datos no válidos marcados solo con un indicador activo de BIT necesitará un AND adicional en la cláusula WHERE para cada consulta desde ahora hasta siempre. Esto ayudará a los usuarios a caer en el pozo del fracaso en lugar del pozo del éxito. Sin embargo, le recomiendo encarecidamente que implemente estos sistemas de banderas de todos modos porque sin un mal diseño, no hay necesidad de que los desarrolladores de mantenimiento corrijan los numerosos errores que creará.
¿Qué valor tiene tener datos históricos en la tabla? Si el negocio mira hacia el futuro, tener datos antiguos en las tablas puede ser simplemente una carga:causa problemas al crear restricciones (todas las restricciones deberán modificarse para excluir los datos que desea que no estén allí). El aseguramiento de la calidad de los datos se complica al tener que volver a identificar continuamente lo que es "basura vieja que tenemos miedo de eliminar pero que nunca queremos volver a usar o actualizar" y las cosas nuevas que nos importan.
¿Se está eliminando porque fue un error? Si la fila corresponde a una entidad en la vida real, tal vez sea interesante mantener y establecer una bandera de "vaporizado", "muerto", "salido del edificio". Si accidentalmente insertó una fila que no corresponde a ninguna entidad en la vida real, un DELETE no es algo malo. ¿Son importantes los clientes imaginarios que nunca existieron para mantenerlos en la tabla de clientes?
Y finalmente, la personalidad juega un papel importante. Las personas también pueden ser obsesivas con los datos. Si un DBA conserva todos sus periódicos de hace 30 años y no le gusta eliminar datos, tal vez debería asegurarse de tomar decisiones de diseño de datos basadas en los méritos y no en una preferencia personal irrelevante.
