En un nuevo programa donde el espacio no es tan importante, ¿es mejor eliminar una fila o deshabilitar una fila digamos booleano "Deshabilitado" y hacer que el programa simplemente lo ignore?¿Debo eliminar o desactivar una fila en una base de datos relacional?
Por ejemplo, si quería eliminar un usuario de un programa.
Es una llamada de juicio, pero he terminado agregando columnas "desactivadas" en las tablas donde previamente pensé que podría eliminar una fila. Yo diría que la mayoría de las veces estás más seguro al agregar una columna desactivada. Sin embargo, esto puede ser complicado con las relaciones n. N, así que eso es algo a considerar.
Depende. (Pero ya lo adivinó, estoy seguro.)
En la práctica, la violación del uso adecuado aquí casi siempre está en la dirección de eliminación.
La principal mala consecuencia de eliminar es la frecuencia con la que existen registros dependientes en otras tablas cuya integridad referencial se pierde cuando el registro principal desaparece.
Un "arenque rojo" utilizado para defender la eliminación (que ya ha tratado correctamente al descartar el problema de la capacidad de almacenamiento), espera que haga una diferencia notable en la eficacia de la consulta.
Hay demasiados casos en los que los problemas de usuario o de software hacen que alguien tenga que presionar el botón grande "Deshacer"; si elimina, no tiene suerte (al menos sin obtener ayuda especial y agravando a las personas con quienes preferiría ser amable)
La terminología que suelo usar es "Activa" e "Inactiva".
algunos puntos más a tener en cuenta (por Totophil):
La legislación de protección de datos puede requerir que su organización, en ciertas circunstancias, elimine cualquier información identificable sobre un individuo. La legislación difiere de un país a otro, algunos consejos:
Por otro lado se le podría exigir por ley a mantener cierta información .
** La terminología que suelo usar es "Activa" e "Inactiva ** ... Casi siempre agrego esto como un campo adicional a las tablas con una clave primaria. Como booleano, ocupa un espacio mínimo y permite datos adecuados. Integridad al dar a la aplicación la eliminación percibida. El único caso en que esto es engorroso es una inserción accidental seguida de supresión inmediata. – Sablefoste
Depende. Si está deshabilitado, entonces es más fácil de recuperar/ver que alguien realmente borró el registro (para auditar).
Es posible que también tenga un requisito técnico para no eliminar registros. Por ejemplo, si desea sincronizar su base de datos con otro usuario simplemente enviando registros modificados, no podrá hacerlo si realmente se eliminó.
Probablemente sea mejor agregar la columna "eliminada" y ofrecer a los usuarios recuperar o eliminar elementos eliminados.
Necesita tenerlo en requisitos funcionales. Si no se dice explícitamente, tendrás que descubrirlo tú mismo.
En la mayoría de los casos, es mejor almacenar dichos registros en una tabla separada. A continuación, evita varias situaciones en las que una tabla hace referencia a otra y debe decidir si los registros de la segunda tabla también se tratarán como eliminados.
No borrar creará una nueva clase de errores para todas las consultas futuras. No olvide que la escritura de consultas a menudo es realizada por usuarios avanzados (es decir, profesionales no informáticos) y desarrolladores junior. Entonces, cada tabla que tenga datos inválidos marcados solo por una bandera activa 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 de en el pozo del éxito. Sin embargo, le recomiendo encarecidamente que implemente estos sistemas de indicadores de todos modos porque sin un mal diseño, no es necesario que los desarrolladores de mantenimiento arreglen los numerosos errores que creará.
¿Qué tan valioso es tener datos históricos en la tabla? Si la empresa está orientada hacia el futuro, tener datos antiguos en las tablas puede ser una carga, ya que puede causar problemas al crear restricciones (todas las restricciones tendrán que modificarse para excluir los datos que no desea). La garantía de la calidad de los datos se complica al tener que volver a identificar continuamente lo que es "basura vieja que tememos eliminar pero nunca queremos usar o actualizar de nuevo" y cosas nuevas que nos importan.
¿Se está borrando porque fue un error? Si la fila corresponde a una entidad en la vida real, tal vez sea interesante mantener y establecer una bandera "vaporizada", "muerta", "abandonada". Si inserta accidentalmente una fila que no corresponde a ninguna entidad en la vida real, un DELETE no es malo. ¿Son importantes los clientes imaginarios que nunca existieron para mantener en la mesa del cliente?
Y, por último, la personalidad juega un papel importante. Las personas pueden ser packrats con datos, también. Si un DBA mantiene todos sus periódicos de hace 30 años y no le gusta borrar datos, tal vez debería asegurarse de que está tomando decisiones de diseño de datos basadas en los méritos y no en una preferencia personal irrelevante.
Si hubiera un problema potencial con los usuarios avanzados al desarrollar consultas, uno podría crear una vista alrededor de la tabla que se filtró las filas "borradas" automáticamente. Difícilmente incluso una cuestión menor, creo. – Chris
Depende de usted y de sus requisitos (algunas cosas se vuelven difíciles cuando existen registros que ... no).
Voy a decir que un booleano es una mala elección, sin embargo. Haz que sea una marca de tiempo que se puede anular. Es bastante útil saber cuándo se borró algo, especialmente cuando borró demasiado y desea deshacer parte de la eliminación.
Esto debe ser determinado por las necesidades de la aplicación. Lo he hecho en ambos sentidos. Tengo algunas aplicaciones que necesitan para ayudar a deshacer, ya que el costo de eliminar una fila, y las eliminaciones en cascada causadas por eso, son demasiado costosas como para no tenerlo. Normalmente, sin embargo, las aplicaciones que he hecho requieren que el usuario confirme las eliminaciones, y luego simplemente haga lo que el usuario solicitó. En algunos casos, debe eliminar los datos debido a problemas de privacidad. Es decir, si el usuario solicita que se elimine, debe realmente eliminarlo, no solo marcarlo como no actual. En otros casos (como transacciones relacionadas con impuestos), puede haber razones para mantener los datos en un estado no actual hasta que la ley ya no los exija. Tengo aplicaciones que se ajustan a ambas categorías.
Se pueden usar varias estrategias en caso de que necesite guardar datos de "archivo". Dependiendo de si debe estar disponible de inmediato, puede presionarlo para archivar tablas que se guardan o se respaldan y se limpian regularmente. Si hay una necesidad de deshacer, es posible que desee mantenerlo en la tabla actual y simplemente marque estableciendo un indicador.Realmente depende en cierta medida de la complejidad de su esquema, los requisitos de la aplicación y las preferencias personales.
Después de leer un libro sobre diseño de base de datos temporal, llegué a creer en la filosofía de que cada registro de importancia temporal debe tener al menos 4 columnas de marca de tiempo. Esos cuatro son: creado, eliminado, inicio, fin. Las marcas de tiempo creadas y eliminadas son bastante autoexplicativas. Su sistema no debería mirar los registros donde está borrado antes de ahora(). Las columnas de inicio y final determinan cuándo los datos se aplican a su sistema. Es para mantener un historial de cambios. Si necesita actualizar un registro, debe establecer su hora de finalización en now(), copiarlo, actualizar la copia y establecer el tiempo de inicio de la copia en now(). De esta manera, cuando necesite ver la forma en que algo fue históricamente, puede hacer que el sistema lo resuelva. También podría establecer el inicio en algún momento en el futuro para que un cambio se realice automáticamente en ese momento, o establecer el final para un momento futuro para que desaparezca automáticamente en ese momento. Establecer las marcas de tiempo creadas/eliminadas para el futuro realmente no tiene sentido ...
¿Qué libro? Parece interesante. – bortzmeyer
Siempre me ha parecido mejor poner este tipo de datos históricos en un almacén de datos separado. Todos los datos históricos son va a ralentizar una tabla grande a paso de tortuga. Además, si realiza muchas inserciones en una tabla, la base de datos debe seguir cambiando los datos para mantener organizado el índice agrupado. –
Agregar una columna "ELIMINADO" a su tabla y marcar filas en lugar de eliminarlas crea mucho más trabajo para usted con poco (si hay)) beneficio. Ahora, cada vez que escribe una consulta, debe recordar incluir "DONDE ELIMINAR NO ES NULO" (o lo que sea).
Un mejor enfoque es eliminar datos cuando necesite eliminar datos, y confíe en su proceso de copia de seguridad habitual para asegurarse de que no se pierda ningún dato. Si por alguna razón necesita mantener algunos datos eliminados a mano (para las búsquedas, tal vez), es mejor simplemente copiar los datos a una tabla diferente creada para este fin y luego eliminar los originales.
He heredado muchas bases de datos a lo largo de los años, y esta estrategia de marcar registros en lugar de eliminarlos es lamentablemente muy común, y (en mi experiencia como mínimo) siempre conduce a problemas importantes en el futuro.
Confío en que sería eliminado! = 'Y' o eliminado = 'N' o similar, no nulos. Y las vistas pueden ser útiles en este punto. –
Vistas = más trabajo y más cosas para mantener. – MusiGenesis
A menos que tenga una necesidad específica de administrar sus propias eliminaciones, es mejor que simplemente borre las filas.
Si utiliza una columna eliminada, visible, inactiva, etc., puede abstraer el hecho de tener que recordar usarla mediante el uso de vistas.
Depende de la función de la base de datos. ¿Es la fuente de toda la verdad? En caso afirmativo, deshabilite en lugar de eliminar, ya que es más fácil de recuperar de las malas operaciones (es decir, error del usuario). Si la base de datos proviene de alguna fuente de datos ascendente, elimine los datos no utilizados. Cualquier recreación/recuperación puede ser realizada por el sistema ascendente.
Si se necesitan los datos eliminados a veces, pero no muy a menudo: se puede mover los registros en una base de datos/tabla separada (por ejemplo users y users_deleted, o mejor somedb.users y somedb_deleted.users).
De esta manera, se puede acceder a los datos a través de una consulta (aunque no será tan simple como la normal), pero no ocupa la base de datos original y no es necesario codificarla.
Me gustaría señalar que hay (en la mayoría de los países) casos de uso en los que no puede eliminar registros por razones legales. La industria y los datos dependen, por supuesto.
En este caso, creo que la guía de mejores prácticas es sombrear la tabla de los datos "eliminados" que le otorga los beneficios de la eliminación real outlined by MatthewMartin y por extensión he llegado a encontrar este patrón frecuentemente preferible a la creación de bits "activos" banderas en mis tablas de datos.
Como ya se ha dicho, la aplicación debe dictar lo que desea hacer. Pero para mí, marcar una fila parece no utilizar la herramienta correcta para lo correcto. Lógicamente, pensamos en una eliminación como un BORRAR, por lo que cuando no se le permite eliminar por razones legales, entonces no la elimina en primer lugar. Al mismo tiempo, pienso en todo el mantenimiento e indexación de la estructura interna de datos. Sin mencionar todas las optimizaciones que se pueden hacer para recuperar datos, pero agregar esa verificación (en la vista o en la consulta) afecta el rendimiento exponencialmente con la complejidad de la base de datos y las relaciones que tienen las entidades.
En pocas palabras, coloque la lógica de eliminación en la capa de la interfaz de usuario para evitar errores del usuario y dar permisos de eliminación a los usuarios que deberían poder eliminarlo. Use copias de seguridad periódicas para guardar los archivos. Si su aplicación requiere absolutamente un historial de auditoría estricto, impleméntelo en desencadenantes y coloque la auditoría en una base de datos externa para evitar todo ese tráfico, comprobar y echar basura de la producción.
Hay dos soluciones adicionales para esto que he usado comúnmente. Estoy de acuerdo con otras personas que han publicado que realmente cumple con los requisitos de sus datos.
Puede evitar que el usuario elimine el registro si causa problemas de integridad referencial mediante el uso de restricciones de clave externa (siempre que su RDBMS lo admita). Algunas veces le he dado un mensaje al usuario final de que "No puede eliminar este objeto < > hasta que desasoce el objeto padre < > con él". Esto puede funcionar siempre y cuando no anticipe que hay un número tremendamente alto de asociaciones con otra tabla o tablas.
Otro enfoque es mover cualquier registro desasociado para asociarlo con un registro que no se elimine. Por ejemplo, supongamos que tiene un curso para el cual están asociados 10 horarios de clase separados. Si elimina el curso, puede permitirle al usuario decidir si se borran las 10 clases o si están asociadas a un curso nuevo o existente.
Estoy creando un CRUD y estoy enfrentando el mismo problema.
Solución: D de CRUD debe deshabilitar en lugar de eliminar.
Problemas:
gran problema
¿Cómo es complicado con los registros de unión? Creo que la misma lógica se aplica a las relaciones como a las entidades. – dkretz
Porque la relación entre los dos registros se puede "eliminar" por sí misma, lo que indica que ya no están relacionados, pero que una vez lo fueron.Ahora, ¿y si alguien quiere volver a agregar la relación? Puede no ser un problema para todas las aplicaciones. – Draemon