¿Deberíamos alguna vez eliminar datos en una base de datos?

Soy nuevo en bases de datos y trato de entender los conceptos básicos. Aprendí a eliminar datos en una base de datos. Pero uno de mis amigos me dijo que nunca debe eliminar datos en una base de datos. Más bien, cuando ya no es necesario, es mejor simplemente marcarlo o marcarlo como 'no en uso'.

¿Es eso cierto? Si es así, ¿cómo manejaría una gran empresa como IBM sus datos durante cien años o más?

Como con todas estas cosas, la respuesta es "depende".

Si es probable que el usuario quiera recuperar los datos, entonces sus amigos tienen razón: en realidad no lo borra, simplemente marque el registro como "borrado". De esta manera, cuando el usuario cambia de opinión, puede recuperar los datos.

Sin embargo, si los datos eliminados tienen más de un cierto período de tiempo (un año, por ejemplo), puede decidir realmente eliminarlos de las tablas en vivo, pero mantenerlos en una tabla de archivo o incluso en una copia de seguridad si el usuario alguna vez lo desea de nuevo De esta manera, puede mantener al mínimo la cantidad de datos (en vivo y recientemente eliminados).

Sin embargo, si los datos son efímeros o se recrean fácilmente, puede decidir eliminarlos realmente.

Hay una clase de datos que se tiene que eliminar - y eso es los datos personales que el usuario no desea que usted mantenga más. Puede haber leyes locales (por ejemplo, en la UE) que lo convierten en un requisito obligatorio (gracias Gavin )

Igualmente, puede haber reglas que requieran que no elimine datos, por lo tanto, antes de decidir algo, consulte con las autoridades reguladoras sobre lo que debe hacer para cumplir con la ley.

Esto es realmente un problema importante para muchas empresas. No hay forma de determinar limpiamente qué datos están realmente en uso, por lo que simplemente se encuentra en la base de datos. La eliminación y el archivo de datos deben ser parte de cada diseño de sistema grande, pero rara vez lo son. La mayoría de las empresas simplemente viven con él, compran discos más grandes y ajustan sus consultas e índices para mantener el rendimiento, hasta que cambian los sistemas y luego realizan un esfuerzo significativo para identificar los datos actuales y luego solo migran esos registros a su nuevo sistema.

Sí, debe eliminar datos de su base de datos, pero a menudo no es simple decir qué y cuándo.

Ya ha habido muchas buenas respuestas a esto que prácticamente se reducen a "Depende de las circunstancias", y no puedo agregar nada a eso.

Sin embargo, una cosa que no se ha mencionado, que creo que debe mencionarse, es que nunca debe reutilizar las claves primarias generadas por una secuencia o un sistema AUTO_INCREMENT.

Cuando elimine un elemento al que se le haya asignado una clave principal mediante dicho sistema, habrá huecos en la columna de clave principal, que quedarán junto a los datos eliminados. Existe una gran tentación de reasignar esas brechas a los nuevos elementos a medida que se agregan, o peor aún, de mezclar los datos existentes para darle una nueva ID para eliminar las brechas, pero hacerlo generará problemas que nunca tendrás que lidiar con eso si dejaste solo las llaves.

Supongamos que mantiene una base de datos de impresoras para gestionar el reordenamiento de consumibles. La impresora 13, una vieja impresora láser, se descompone más allá de la reparación económica, por lo que la descarta. Mientras tanto, por una razón no relacionada, alguien solicita una nueva impresora térmica para imprimir códigos de barras en el almacén, y esa impresora llega antes de reemplazar la impresora 13. El administrador registra esa nueva impresora en la base de datos y, porque 13 ahora está libre y está reciclando ID, la nueva impresora térmica recibe 13 como ID.

Ahora alguien le dice que la impresora 13 está casi sin tinta. Recuerda que la impresora 13 es una impresora láser, por lo que no se molesta en buscarla en la base de datos y realiza un pedido de un cartucho de tóner. Solo que realmente necesitaba pedir un paquete de tinta térmica porque la impresora 13 ya no es una impresora láser. Cuando llega el cartucho de tóner, no puede usarlo porque es la recarga de tinta incorrecta para la impresora, no puede imprimir más códigos de barras y no puede enviar ningún pedido a la espera de ser enviado.

Peor aún, ¿qué sucede si elimina la impresora 13 y baraja todas las impresoras que vienen después para llenar el vacío? La impresora 14 (alguna matriz de puntos antigua decrépita) se convierte en la impresora 13, la impresora 15 se convierte en la impresora 14 y así sucesivamente.

Todas las impresoras tienen etiquetas para poder hacer referencias cruzadas con la base de datos, pero ahora todas las etiquetas están desactualizadas. Tendrá que dar vueltas, localizar todas las impresoras en el negocio (¡que podrían llegar a cientos!) Y volver a etiquetarlas. Eso no es un uso efectivo del tiempo. Y también es un proceso propenso a errores, y ¿qué sucede si nunca se hace? Alguien llama para decir que la impresora 14 se ha averiado y necesita repararse con urgencia, por lo que debe buscarla y descubrir que la impresora 14 es una impresora de inyección de tinta en la recepción. Solo porque ha barajado las identificaciones, en realidad es la impresora de matriz de puntos la que necesita repararse con urgencia. El tipo que llamó al problema queda pendiente, mientras que la recepcionista tiene un tipo de soporte técnico al que nunca llamó para que reparase una impresora que no estaba rota.

Debería pensar en las ID asignadas por un sistema de incremento automático como permanentes, son inmutables y no se pueden reutilizar, incluso si la cosa a la que se refiere la ID deja de existir. Algunas personas afirman que no quieren tener que preocuparse de que se agoten las ID, pero incluso con sistemas de 32 bits e ID firmadas, todavía hay 2 mil millones de ID disponibles. Si puede hacer que la columna de ID no esté firmada, esto se duplica a 4 mil millones, y en los sistemas de 64 bits el número de ID disponibles es literalmente mayor que el número de estrellas en el cielo. No te quedarás sin ID.

Muchas buenas respuestas aquí ya. Solo quiero agregar una situación que nadie ha mencionado todavía:

Los datos sensibles . Si el usuario lo elimina, ¡será mejor que lo elimine!

Una situación muy común que viene a la mente es cambiar / restablecer contraseña. No querrá almacenar contraseñas antiguas (aunque sean hash, saladas, etc.) en su base de datos. Los usuarios pueden estar usando sus contraseñas antiguas (y malas) en otros sitios.

Además, cuando se trata de leyes sobre cuánto tiempo se le permite almacenar ciertos tipos de datos, por supuesto, las eliminaciones suaves no lo harán. Tienes que eliminarlo realmente.

Entonces me preguntaría: ¿se enojará el usuario (o alguien más, por ejemplo, el gobierno) si les hago creer que los datos han sido eliminados, pero de hecho todavía los tengo y puedo restaurarlos en cualquier momento?

Generalmente no elimino los datos del usuario en mis bases de datos. Los señalo para que estén ocultos. Con demasiada frecuencia, un usuario elimina algo accidentalmente y necesita reemplazarlo fácilmente. También ayuda a conservar la integridad referencial para los datos relacionados. Esto funciona para bases de datos de tamaño pequeño a moderado. En los sistemas donde el rendimiento se ve muy afectado por esta decisión, se maneja de manera especial, por ejemplo, tablas de archivo, copias de seguridad automáticas, etc.

Descartamos los datos de back-end según sea necesario, por ejemplo, datos de sesión de sitio web caducados e información de registro anterior. No tiene sentido mantenerlos para siempre.

Sin embargo, como de costumbre, la respuesta exacta realmente depende de la situación específica.

He estado trabajando en una solicitud de cambio de divisas durante un par de años cuando surgió esto. Los datos que la aplicación recopiló a lo largo de los años tuvieron un impacto en el rendimiento (digamos exponencial).

Después de hacer lo que pudimos en términos de código, le propusimos a la gerencia que archivara datos con más de un año de antigüedad. Verificaron el concepto (cuestiones legales) y afortunadamente pudimos hacerlo. Así que eliminamos pero también archivamos los datos para que las empresas aún pudieran ejecutar sus informes, etc.

En la mayoría de los casos, debe conservar los datos por si los necesita en el futuro. Es posible que la empresa para la que trabaje desee ver los datos históricos para basar sus decisiones en lo que conducirá a la empresa en una determinada dirección.

Debe agregar columnas 'Date_Time_Removed' a cada tabla y luego, en lugar de eliminar físicamente las filas, establezca una fecha y hora en que la fila se haya eliminado virtualmente. Luego, en sus procedimientos almacenados o sql, factorizaría en la columna 'Date_Time_Removed', por ejemplo, seleccione bla de la tabla1 donde date_time_removed es nulo

Por supuesto, las filas que se han agregado accidentalmente a una base de datos deben eliminarse permanentemente, especialmente los datos de prueba.

Al mantener todos los datos legítimos, también tiene la opción de utilizar su base de datos para el almacenamiento en el futuro.

Otra situación que otras presentadas es cuando se eliminan los datos, pero los registros de operaciones realizadas en la base de datos (eliminación incluida) se almacenan en archivos durante un largo período de tiempo. El alcance principal de esto es implementar un sistema de reversión a fechas pasadas, pero también se puede usar para almacenar de alguna manera los datos eliminados (que se eliminan de la base de datos, pero se almacenan en archivos).

Almacenar archivos de datos eliminados no sería tan importante. Las grandes compañías también pueden almacenar versiones de código y mucha más información (por no hablar de cosas no técnicas), por lo que al final almacenar grandes datos es algo habitual para ellos.