Implementación de eliminación suave con un impacto mínimo en el rendimiento y el código

Question

Hay algunos similar preguntas Sobre el tema, pero realmente no me están ayudando.

Quiero implementar una función de eliminación suave como en StackOverflow, donde los elementos no se eliminan realmente, sino que solo están ocultos. Estoy usando una base de datos SQL. Aquí hay 3 opciones:

• Agrega un is_deleted campo booleano.

  • Ventajas: Simple.
  • Desventajas: sin registro de fecha. Me obliga a agregar un is_deleted = 0 en cada consulta.

• Agrega un deleted_date campo de fecha. Esto está establecido en NULL Si no se elimina.

  • Ventajas: tiene fecha.
  • Desventajas: todavía abarrotando mis consultas.

Para los dos anteriores

• También afectará el rendimiento porque hay todas estas filas inútiles. Todavía tienen que mantenerse en índices. También un índice en el deleted La columna no ayudará al obtener no eliminar (la mayoría) de las filas. Se necesita escaneo de mesa completo.

Otra opción es crear una tabla separada para mantener los elementos eliminados:

• Ventajas: rendimiento mejorado al consultar filas no eliminadas. No es necesario agregar condiciones a mis consultas en filas no eliminadas. Más fácil en el mantenimiento del índice.
• Desventajas: Complejidad: requiere la migración de datos para la eliminación y la falta de línea. Necesidad de nuevas tablas. La integridad referencial es más difícil de manejar.

¿Hay alguna opción mejor?

Answer 1

Si la tecla es numérica, manejo una "delemento suave" al negar la clave. (Por supuesto, no funcionará para las claves de identidad). No necesita cambiar su código en absoluto y puede restaurar fácilmente el registro multiplicando por -1.

Solo otro enfoque para pensar en ... Si la clave es alfanumérica, puede hacer algo similar al preparar los personajes únicos de "marcador". Dado que los registros eliminados comenzarán con este marcador, entonces terminará solo en el índice.

Answer 2

Personalmente, basaría mi respuesta en la frecuencia con la que anticipa que sus usuarios desean acceder a que eliminaran los datos o "restaurar" que eliminaban los datos.

Si es a menudo, entonces iría con un campo "date_deleted" y pondría un "ISDELELED calculado" en mi POCO en el código.

Si nunca (o casi nunca), una tabla de historial o una tabla eliminada es buena para los beneficios que explicó.

Personalmente, casi nunca uso tablas eliminadas (y opto por isDeleted o date_deleted) debido al riesgo potencial de integridad de referencia. Tiene un -> B y elimina el registro de la base de datos B ... Ahora tiene que administrar la integridad de referencia debido a su elección de diseño.

Answer 3

En mi opinión, la mejor manera de seguir, al pensar en el escala y los eventuales tamaños de tabla/base de datos es su tercera opción: una tabla separada para elementos eliminados. Tal tabla eventualmente se puede mover a una base de datos diferente para admitir el escala.

Creo que ha enumerado las tres opciones más comunes. Como ha visto, cada uno tiene ventajas y desventajas. Personalmente, me gusta tener la visión más larga de las cosas.

Answer 4

Supongamos que creamos un campo llamado dead para marcar filas eliminadas. Podemos crear un índice donde campo dead Es falso. De esta manera, solo buscamos filas no eliminadas utilizando el índice de sugerencias de uso.

Answer 5

Creo que su análisis de las opciones es bueno, pero se perdió algunos puntos relevantes que enumero a continuación. Casi todas las implementaciones que he visto usan algún tipo de campo eliminado o de versiones en la fila, como sugiere en sus dos primeras opciones.

Usando una mesa con bandera eliminada:Si todos sus índices contienen primero el campo de indicador eliminado y su consulta contiene principalmente una estructura de tipo ISDELELED = FALSO, entonces resuelve sus problemas de rendimiento y los índices excluyen de manera muy eficiente las filas eliminadas. Se podría usar una lógica similar para la opción Fecha eliminada.

Usando dos tablasEn general, debe realizar cambios masivos en los informes porque algunos informes pueden referirse a datos eliminados (como las cifras de ventas antiguas pueden referirse a una categoría de ventas eliminada). Uno puede superar esto creando una visión que es una unión de las dos tablas para leer y solo escribir en la tabla de registros activos.