sql - logica - Eliminación física vs. lógica/suave del registro de la base de datos?

eliminacion logica php (22)

¡Bien! Como todos dijeron, depende de la situación.

Si tiene un índice en una columna como UserName o EmailID, y nunca espera que se vuelva a utilizar el mismo nombre de usuario o ID de correo electrónico; puedes ir con una eliminación suave.

Dicho esto, siempre verifique si su operación SELECCIONAR usa la clave primaria. Si su instrucción SELECT usa una clave principal, agregar una bandera con la cláusula WHERE no haría mucha diferencia. Tomemos un ejemplo (Pseudo):

Usuarios de tabla (ID de usuario [clave principal], ID de correo electrónico, IsDeleted)

SELECCIONE * FROM Usuarios donde UserID = 123456 e IsDeleted = 0

Esta consulta no hará ninguna diferencia en términos de rendimiento ya que la columna UserID tiene una clave principal. Inicialmente escaneará la tabla en función de PK y luego ejecutará la siguiente condición.

Casos en los que las eliminaciones suaves no pueden funcionar en absoluto:

Regístrese en los principales sitios web y tome EmailID como su identificación única. Sabemos muy bien que, una vez que se utiliza un EmailID en un sitio web como Facebook, G +, no puede ser utilizado por nadie más.

Llega un día en que el usuario desea eliminar su perfil del sitio web. Ahora, si realiza una eliminación lógica, ese usuario no podrá volver a registrarse nunca más. Además, registrarse nuevamente usando el mismo EmailID no significaría restaurar todo el historial. Todos saben, eliminación significa eliminación. En tales escenarios, tenemos que hacer una eliminación física. Pero para mantener todo el historial de la cuenta, siempre debemos archivar dichos registros en tablas de archivo o tablas eliminadas.

Sí, en situaciones donde tenemos muchas mesas extrañas, el manejo es bastante engorroso.

También tenga en cuenta que las eliminaciones suaves / lógicas aumentarán el tamaño de su tabla, por lo que el tamaño del índice.

¿Cuál es la ventaja de hacer una eliminación lógica / suave de un registro (es decir, establecer una bandera que indique que se eliminó el registro) en lugar de borrarlo de manera física o real?

¿Es esta práctica común?

¿Esto es seguro?

¿Los borrados lógicos son una práctica común? Sí, he visto esto en muchos lugares. ¿Están seguros? Eso realmente depende de si son menos seguros que los datos antes de eliminarlos.

Cuando era un líder tecnológico, exigía que nuestro equipo conservara todos los datos, sabía en ese momento que usaríamos toda esa información para construir varias aplicaciones de BI, aunque en ese momento no sabíamos cuáles serían los requisitos. ser. Si bien esto era bueno desde el punto de vista de auditoría, solución de problemas e informes (este era un sitio de comercio electrónico / herramientas para transacciones B2B, y si alguien utilizaba una herramienta, queríamos registrarlo incluso si su cuenta se desactivaba más tarde), sí tuvo varias desventajas.

Las desventajas incluyen (sin incluir otras ya mencionadas):

Repercusiones en el rendimiento de mantener todos esos datos. Desarrollamos diversas estrategias de archivo. Por ejemplo, un área de la aplicación se estaba acercando a generar alrededor de 1 Gb de datos por semana.
El costo de mantener los datos crece con el tiempo, mientras que el espacio en el disco es barato, la cantidad de infraestructura para mantener y administrar los datos en línea y fuera de línea es mucho. Se necesita mucho disco para la redundancia y el tiempo de las personas para garantizar que las copias de seguridad se muevan rápidamente, etc.

Al decidir usar eliminaciones lógicas, físicas o archivar, me haría estas preguntas:

Es esta información que podría necesitar ser reinsertada en la tabla. Por ejemplo, las cuentas de usuario se ajustan a esta categoría ya que puede activar o desactivar una cuenta de usuario. Si este es el caso, una eliminación lógica tiene más sentido.
¿Hay algún valor intrínseco en el almacenamiento de los datos? Si es así, ¿cuántos datos se generarán? Dependiendo de esto, iría con una eliminación lógica o implementaría una estrategia de archivo. Tenga en cuenta que siempre puede archivar registros borrados lógicamente.

Casi siempre borro suavemente y aquí mis 2 centavos:

puede restaurar datos eliminados si un cliente le pide que lo haga. Clientes más felices con eliminaciones suaves. Restaurar datos específicos de copias de seguridad es complejo
la comprobación de isdeleted todas partes no es un problema, debe verificar el userid de userid todos modos (si la base de datos contiene datos de varios usuarios). Puede aplicar el cheque por código, colocando esos dos controles en una función separada (o use vistas)
Eliminar con gracia Los usuarios o procesos que tratan con contenido eliminado continuarán "viéndolo" hasta que lleguen a la siguiente actualización. Esta es una característica muy deseable cuando un proceso procesa algunos datos que se borran repentinamente
Sincronización: si necesita diseñar un mecanismo de sincronización entre una base de datos y aplicaciones móviles, encontrará eliminaciones suaves que son menos dolorosas. Básicamente se evitan las paradojas de sincronización al mover el problema de un loco ADD / UPDATE / DELETE a un ADD / UPDATE más simple

Eliminaciones lógicas si son difíciles para la integridad referencial.

Es lo correcto pensar cuando hay un aspecto temporal de los datos de la tabla (son válidos FROM_DATE - TO_DATE).

De lo contrario, mueva los datos a una tabla de auditoría y elimine el registro.

En el lado positivo:

Es la forma más fácil de deshacer (si es posible).

Es fácil ver cuál era el estado en un punto específico en el tiempo.

Es bastante estándar en los casos en los que le gustaría mantener un historial de algo (por ejemplo, cuentas de usuario como menciona @Jon Dewees). Y ciertamente es una gran idea si hay una gran posibilidad de que los usuarios soliciten anulaciones.

Si le preocupa que la lógica de filtrar los registros eliminados de sus consultas se complique y complique sus consultas, puede crear vistas que filtren por usted y usar consultas en contra de eso. Se evitará la fuga de estos registros en las soluciones de informes y tal.

Estoy totalmente en desacuerdo con la eliminación lógica porque estás expuesto a muchos errores.

En primer lugar, las consultas deben ocuparse del campo IsDeleted y la posibilidad de error aumenta con las consultas complejas.

Segundo, el rendimiento: imagine una tabla con 100000 recs con solo 3 activos, ahora multiplique este número para las tablas de su base de datos; Otro problema de rendimiento es un posible conflicto con los registros nuevos con los antiguos (registros eliminados).

La única ventaja que veo es el historial de registros, pero existen otros métodos para lograr este resultado, por ejemplo, puede crear una tabla de registro donde puede guardar información: TableName,OldValues,NewValues,Date,User,[..] donde *Values pueden ser varchar y escribir los detalles en este formulario fieldname : value ; [..] o almacena la información como xml .

Todo esto se puede lograr a través del código o Triggers pero solo eres UNA tabla con toda tu historia. Otra opción es ver si el motor de base de datos especificado es soporte nativo para el cambio de seguimiento; por ejemplo, en la base de datos de SQL Server hay un cambio de datos de rastreo SQL.

Hay requisitos más allá del diseño del sistema que deben ser respondidos. ¿Cuál es el requisito legal o estatutario en la retención de registros? Dependiendo de con qué se relacionan las filas, puede haber un requisito legal de que los datos se mantengan durante un cierto período de tiempo después de que se ''suspendan''.

Por otro lado, el requisito puede ser que una vez que el registro se "borre", se elimine verdadera e irrevocablemente. Antes de tomar una decisión, hable con sus partes interesadas.

La mayoría de las veces se utiliza el borrado suave porque no desea exponer algunos datos, pero debe conservarlos por razones históricas (un producto podría dejar de fabricarse, por lo que no desea realizar ninguna transacción nueva, pero aún necesita trabajar con él). la historia de la transacción de venta). Por cierto, algunos están copiando el valor de información del producto en los datos de transacción de venta en lugar de hacer una referencia al producto para manejarlo.

De hecho, parece más una nueva redacción para una función visible / oculta o activa / inactiva. Porque ese es el significado de "eliminar" en el mundo de los negocios. Me gustaría decir que los Terminators pueden eliminar a las personas, pero el jefe solo las despide.

Esta práctica es un patrón bastante común y utilizada por muchas aplicaciones por muchas razones. Como no es la única forma de lograr esto, tendrás miles de personas que dicen que eso es genial o tonto y ambos tienen argumentos bastante buenos.

Desde un punto de vista de seguridad, SoftDelete no reemplazará el trabajo de Auditoría y tampoco reemplazará el trabajo de respaldo. Si tiene miedo de "insertar / eliminar entre dos casos de copia de seguridad", debe leer acerca de los modelos de recuperación total o masiva. Admito que SoftDelete podría hacer que el proceso de recuperación sea más trivial.

Depende de ti conocer tu requerimiento.

Las aplicaciones móviles que dependen de la sincronización pueden imponer el uso de eliminación lógica en lugar de física: un servidor debe poder indicar al cliente que un registro se ha eliminado (marcado como), y esto podría no ser posible si los registros se borraron físicamente.

Las ventajas son que mantiene el historial (es bueno para la auditoría) y no tiene que preocuparse de conectar en cascada una eliminación a través de otras tablas en la base de datos que hacen referencia a la fila que está eliminando. La desventaja es que debe codificar cualquier método de informe / visualización para tener en cuenta la bandera.

En cuanto a si es una práctica común, yo diría que sí, pero como con cualquier cosa, si la usa depende de las necesidades de su negocio.

EDITAR: Pensó en otra desventaja: si tiene índices únicos en la tabla, los registros eliminados seguirán ocupando el registro "uno", por lo que también debe codificar esa posibilidad (por ejemplo, una tabla de Usuario que tenga un índice único en nombre de usuario; Un registro eliminado aún bloquearía el nombre de usuario de los usuarios eliminados para nuevos registros. Al trabajar con esto, podría agregar un GUID a la columna de nombre de usuario eliminado, pero es una solución muy hacky que no recomendaría. Probablemente en esa circunstancia lo haría Sería mejor tener una regla que una vez que se utiliza un nombre de usuario, nunca se pueda reemplazar.

No permiten que la base de datos funcione como debería, haciendo inútiles funciones tales como la funcionalidad de cascada.

Para cosas simples como inserciones, en el caso de volver a insertar, el código detrás de él se duplica.

No puede simplemente insertar, en su lugar debe verificar si existe una existencia e insertarla si no existe antes o actualizar la bandera de eliminación si lo hace, mientras que también actualiza todas las otras columnas a los nuevos valores. Esto se ve como una actualización del registro de transacciones de la base de datos y no como una nueva inserción que causa registros de auditoría inexactos.

Causan problemas de rendimiento porque las tablas se aglutinan con datos redundantes. Juega estragos con la indexación, especialmente con la singularidad.

No soy un gran admirador de eliminaciones lógicas.

Normalmente utilizo eliminaciones lógicas: creo que funcionan bien cuando también archiva de manera intermitente los datos ''eliminados'' en una tabla archivada (que puede buscarse si es necesario) y no tiene posibilidad de afectar el rendimiento de la aplicación.

Funciona bien porque todavía tienes los datos si alguna vez te auditan. ¡Si lo borras físicamente, se va !

Para dar una alternativa, tenemos usuarios que usan dispositivos remotos que se actualizan a través de MobiLink. Si borramos registros en la base de datos del servidor, esos registros nunca se borran en las bases de datos del cliente.

Entonces hacemos ambas cosas. Trabajamos con nuestros clientes para determinar cuánto tiempo desean poder recuperar los datos. Por ejemplo, generalmente los clientes y los productos están activos hasta que nuestro cliente dice que deberían eliminarse, pero el historial de ventas solo se conserva durante 13 meses y luego se elimina automáticamente. El cliente puede querer mantener clientes y productos eliminados durante dos meses, pero conservará el historial durante seis meses.

Entonces, ejecutamos un script de la noche a la mañana que marca las cosas borradas lógicamente de acuerdo con estos parámetros y luego, dos o seis meses después, todo lo que se marque como borrado lógicamente hoy será eliminado.

Nos importa menos la seguridad de los datos que tener enormes bases de datos en un dispositivo cliente con memoria limitada, como un teléfono inteligente. Un cliente que solicita 200 productos dos veces por semana durante cuatro años tendrá más de 81,000 líneas de historial, de las cuales al 75% al cliente no le importa si lo ve.

Para responder al comentario de Tohid, enfrentamos el mismo problema en el que queríamos conservar el historial de los registros y tampoco estábamos seguros de si queríamos la columna is_deleted o no.

Estoy hablando de nuestra implementación python y un caso de uso similar que acertamos.

Nos encontramos con https://github.com/kvesteri/sqlalchemy-continuum que es una manera fácil de obtener la tabla de versiones para su tabla correspondiente. Mínimas líneas de código y el historial de capturas para agregar, eliminar y actualizar.

Esto sirve más que simplemente la columna is_deleted . Siempre puede retroceder la tabla de versiones para verificar lo que sucedió con esta entrada. Si la entrada se eliminó, actualizó o agregó.

De esta forma, no necesitábamos tener la columna is_deleted en absoluto y nuestra función de eliminación era bastante trivial. De esta forma, tampoco es necesario recordar marcar is_deleted=False en cualquiera de nuestras api.

Puede ser un poco tarde, pero sugiero que todos revisen la entrada del blog de Pinal Dave sobre la eliminación lógica / suave:

Simplemente no me gusta este tipo de diseño [eliminación suave] en absoluto. Creo firmemente en la arquitectura donde solo los datos necesarios deberían estar en una sola tabla y los datos inútiles deberían moverse a una tabla archivada. En lugar de seguir la columna isDeleted, sugiero el uso de dos tablas diferentes: una con órdenes y otra con órdenes eliminadas. En ese caso, deberá mantener ambas tablas, pero en realidad, es muy fácil de mantener. Cuando escriba la instrucción UPDATE en la columna isDeleted, escriba INSERT INTO another table y SUPRIMA de la tabla original. Si la situación es de reversión, escriba otro INSERT INTO y DELETE en orden inverso. Si le preocupa una transacción fallida, ajuste este código en TRANSACTION.
¿Cuáles son las ventajas de la tabla más grande de versículos más pequeños en las situaciones descritas anteriormente?
Una mesa más pequeña es fácil de mantener
Las operaciones de reconstrucción de índices son mucho más rápidas
Mover los datos de archivo a otro grupo de archivos reducirá la carga del grupo de archivos primario (teniendo en cuenta que todos los grupos de archivos están en un sistema diferente), esto también acelerará la copia de seguridad.
Las estadísticas se actualizarán frecuentemente debido a un tamaño más pequeño y esto requerirá menos recursos.
El tamaño del índice será más pequeño
El rendimiento de la tabla mejorará con un tamaño de tabla más pequeño.

Re: "¿Esto es seguro?" - Eso depende de lo que quieras decir.

Si quiere decir que al hacer una eliminación física, evitará que alguien encuentre los datos eliminados , entonces sí, eso es más o menos cierto; está más seguro eliminando físicamente los datos confidenciales que deben borrarse, porque eso significa que se ha ido de forma permanente de la base de datos. (Sin embargo, tenga en cuenta que puede haber otras copias de los datos en cuestión, como en una copia de seguridad o el registro de transacciones, o una versión grabada en tránsito, por ejemplo, un rastreador de paquetes; simplemente porque lo elimine de su base de datos no lo hace garantizar que no fue guardado en otro lugar.)

Si quiere decir que al hacer una eliminación lógica, sus datos son más seguros porque nunca perderá ningún dato , eso también es cierto. Esto es bueno para escenarios de auditoría; Tiendo a diseñar de esta manera porque admite el hecho básico de que una vez que se generan los datos, nunca desaparecerán (especialmente si alguna vez tuvieron la capacidad de ser almacenados, por ejemplo, en un buscador de Internet). Por supuesto, un escenario de auditoría real requiere que las eliminaciones no solo sean lógicas, sino que también se registren las actualizaciones, junto con el momento del cambio y el actor que realizó el cambio.

Si quiere decir que los datos no caerán en manos de nadie que no debería verlos, eso depende totalmente de su aplicación y de su estructura de seguridad. En ese sentido, la eliminación lógica no es más o menos segura que cualquier otra cosa en su base de datos.

Soft Delete es una práctica de programación que se sigue en la mayoría de las aplicaciones cuando los datos son más relevantes. Considere un caso de aplicación financiera donde una eliminación por el error del usuario final puede ser fatal. Ese es el caso cuando la eliminación suave se vuelve relevante. En la eliminación suave, el usuario no está eliminando realmente los datos del registro en lugar de marcarlos como IsDeleted a verdadero (por convención normal).

En EF 6.x o EF 7 en adelante, Softdelete se agrega como un atributo, pero tenemos que crear un atributo personalizado por el momento.

Recomiendo encarecidamente SoftDelete en un diseño de base de datos y es una buena convención para la práctica de programación.

Solía hacer borrado suave, solo para mantener registros antiguos. Me di cuenta de que los usuarios no se molestan en ver los registros antiguos tan a menudo como pensaba. Si los usuarios desean ver registros antiguos, simplemente pueden verlos desde el archivo o la tabla de auditoría, ¿verdad? Entonces, ¿cuál es la ventaja de la eliminación suave? Solo lleva a una declaración de consulta más compleja, etc.

Las siguientes son las cosas que he implementado, antes de que decidiera no borrarlas más:

implementar auditoría, para registrar todas las actividades (agregar, editar, eliminar). Asegúrese de que no haya ninguna clave externa vinculada a la auditoría, y asegúrese de que esta tabla esté segura y que nadie pueda eliminarla, excepto los administradores.
identificar qué tablas se consideran "tabla transaccional", que es muy probable que se conserven durante mucho tiempo, y es muy probable que el usuario desee ver los registros o informes pasados. Por ejemplo; transacción de compra. Esta tabla no solo debe mantener el ID de la tabla maestra (como por ejemplo, dept-id), sino también la información adicional, como el nombre como referencia (como el nombre del departamento) o cualquier otro campo necesario para informar.
Implemente el registro "activo / inactivo" o "activar / desactivar" u "ocultar / mostrar" de la tabla maestra. Por lo tanto, en lugar de eliminar el registro, el usuario puede desactivar / inactivar el registro maestro. Es mucho más seguro de esta manera.

Solo mi opinión de dos centavos.

Soy desarrollador de NoSQL, y en mi último trabajo, trabajé con datos que siempre fueron críticos para alguien, y si se eliminaron accidentalmente en el mismo día en que se crearon, no pude encontrarlos en la última copia de seguridad. ¡de ayer! En esa situación, la eliminación suave siempre guardaba el día.

Hice borrado suave utilizando marcas de tiempo, registrando la fecha en que se eliminó el documento:

IsDeleted = 20150310 //yyyyMMdd

Todos los domingos, un proceso caminó en la base de datos y verificó el campo IsDeleted . Si la diferencia entre la fecha actual y la marca de tiempo fue mayor a N días, el documento se eliminó por completo. Teniendo en cuenta que el documento aún estaría disponible en algunas copias de seguridad, era seguro hacerlo.

EDITAR: Este caso de uso de NoSQL se trata de documentos grandes creados en la base de datos, decenas o cientos de ellos todos los días, pero no miles o millones. Por lo general, eran documentos con el estado, los datos y los archivos adjuntos de los procesos de flujo de trabajo. Esa fue la razón por la cual existía la posibilidad de que un usuario elimine un documento importante. Este usuario podría ser alguien con privilegios de administrador, o tal vez el propietario del documento, solo por nombrar algunos.

TL; DR Mi caso de uso no era Big Data. En ese caso, necesitarás un enfoque diferente.

Soy un gran admirador de la eliminación lógica, especialmente para una aplicación de línea de negocios, o en el contexto de cuentas de usuario. Mis razones son simples: muchas veces no quiero que un usuario pueda usar el sistema (para que la cuenta se marque como eliminada), pero si eliminamos al usuario, perderíamos todo su trabajo y tal.

Otro escenario común es que los usuarios pueden volver a crear un tiempo después de haber sido eliminado. Es una experiencia mucho más agradable para el usuario tener todos sus datos presentes tal como estaban antes de que fueran eliminados, en lugar de tener que volver a crearlos.

Normalmente pienso en eliminar más a los usuarios como "suspenderlos" indefinidamente. Nunca se sabe cuándo legítimamente necesitarán regresar.

Todo depende del caso de uso del sistema y sus datos.

Por ejemplo, si está hablando de un sistema regulado por el gobierno (por ejemplo, un sistema en una compañía farmacéutica que se considera parte del sistema de calidad y debe seguir las pautas de la FDA para registros electrónicos), ¡mejor no hacer eliminaciones difíciles! Un auditor de la FDA puede ingresar y solicitar todos los registros del sistema relacionados con el número de producto ABC-123, y todos los datos estarán mejor disponibles. Si el propietario de su proceso empresarial dice que el sistema no debe permitir que nadie use el número de producto ABC-123 en los registros nuevos en el futuro, use el método de eliminación suave para hacerlo "inactivo" dentro del sistema, mientras conserva los datos históricos.

Sin embargo, tal vez su sistema y sus datos tienen un caso de uso como "seguimiento del clima en el Polo Norte". Tal vez tome lecturas de temperatura una vez por hora, y al final del día agregue un promedio diario. Tal vez los datos por hora ya no se utilizarán después de la agregación, y se eliminarán las lecturas por hora después de crear el agregado. (Este es un ejemplo inventado y trivial)

El punto es que todo depende del caso de uso del sistema y sus datos, y no de una decisión puramente desde un punto de vista tecnológico.

Un patrón que he usado es crear una tabla espejo y adjuntar un desencadenador en la tabla principal, de modo que todas las eliminaciones (y las actualizaciones si se desea) se graban en la tabla espejo.

Esto le permite "reconstruir" registros eliminados / modificados, y aún puede eliminarlos en la tabla principal y mantenerlos "limpios"; también permite la creación de una función de "deshacer" y también puede registrar la fecha y la hora. , y el usuario que hizo la acción en la mesa de espejo (muy valioso en situaciones de caza de brujas).

La otra ventaja es que no hay posibilidad de incluir accidentalmente registros eliminados al realizar consultas en el servidor primario, a menos que deliberadamente se tome la molestia de incluir registros de la tabla espejo (es posible que desee mostrar registros en vivo y eliminados).

Otra ventaja es que la mesa espejo puede purgarse independientemente, ya que no debe tener ninguna referencia de clave externa real, haciendo que esta sea una operación relativamente simple en comparación con la purga de una tabla principal que usa eliminaciones suaves, pero que aún tiene conexiones de referencia con otras tablas .

¿Qué otras ventajas? - genial si tienes un grupo de codificadores trabajando en el proyecto, haciendo lecturas en la base de datos con habilidades mixtas y atención a los niveles de detalle, no tienes que quedarte despierto esperando que uno de ellos no se olvide de incluir eliminado registros (lol, No Incluir Registros Eliminados = Verdadero), lo que da como resultado exagerar, por ejemplo, la posición de efectivo disponible del cliente con la que luego compran algunas acciones (es decir, como en un sistema de negociación), cuando trabajas con sistemas de negociación, Descubrirá muy rápidamente el valor de las soluciones robustas, a pesar de que pueden tener un poco más de "gastos generales" iniciales.

Excepciones: como guía, utilice eliminaciones suaves para datos de "referencia", como usuario, categoría, etc., y eliminaciones completas en una tabla espejo para datos de tipo "hechos", es decir, historial de transacciones.