Delete or Not delete

[germonti]

Hace unos días tuve una discución con una compañero, en la cual sometiamos a la disputa si era mala idea o buena idea borrar registros de una base de datos. Uno decia que NUNCA se debia borrar un registro, que registro y dato era lo mismo, y que no importaba lo que el cliente pidiera. EL otro que existian casos en que borrar un registro era esperable, no dañaba la base ni el negocio, que registro y dato son cosas distintas y que debiamos señirnos a lo que pidiera el cliente. Antento a lo acalorado de la discusión, someto a ustedes el tema para formar mi opinión. Gracias

[cuchurrumin]

ps vaya que que ganas de pelear pero bueno, partiendo de que en una base de datos se puede manejar borrado logico o borrado fisico, y de q un dato no es un registro por lo general se sule llamar registro a toda la fila que se inserta en una base de datos... regresando al borrado depende de las necesidades del cliente hay informacion q no se requiere almacenada y seria inutil no borrarla, asi que creo q todo depende de la necesidad o no de la informacion.

[germonti]

ese era uno de los puntos, lo que quisiera el cliente, a lo que el otro respondía, que en ese caso se debia solo desabilitar la lectura, pero no borrar los registros. Gracias por tu respuesta.

[gnzsoloyo]

El problema es que el cliente tiende a pedir lo que cree que le sirve, pese a que son contadas las ocasiones en que el mismo tiene suficientes conocimientos como para percatarse que está pidiendo bobadas.

En una base de datos relacional los registros, la inmensa mayoría de las veces, no pueden borrarse sin generar inconsistencia de datos. Esa restricción es prácticamente inevitable; las excepciones están dadas solamente en el contexto de cada modelo de datos, no hay una regla general.

El punto que muchas veces no ve el cliente, es que la información y los datos no solamente no deben borrarse por las inconsistencias, sino porque toda información, por superflua que parezca, puede eventualmente permitir desarrollar inteligencia de negocios (BI), que es el bien más preciado de cualquier rama de las empresas.

Precisamente por eso, los datos innecesarios no se eliminan, sino que se almacenan en datawarehouses (DW), o datamarts (DM), que representan unidades de información acumulada históricamente y pueden ser usados en todo tipo de planeamiento estratégico. Esos datos no se pueden suplantar con una encuesta, o un relevamiento, porque las encuestas y relevamientos marcan solamente tendencias presentes a corto plazo, mientras que el uso de DW y DM permiten establecer tendencias a futuro. Y es en el futuro donde se juega la existencia de las empresas.

Sin descartar lo antedicho, una de las restricciones que los clientes también olvidan, es que la documentación administrativa y comercial de una empresa debe ser guardada durante un número de años, conforme las leyes del país donde residen, y los datos almacenados en las bases se consideran documentación electrónica, a los efectos de auditorias...

Esta una visión que hay que tener muy en cuenta, y que el cliente habitualmente no percibe hasta que ya es demasiado tarde. Solamente los profesionales de TI pueden lograr hacerle ver lo dañino de la destrucción de información.

Por estas y otras muchas consideraciones, es que son muy puntuales los casos en que pueda considerarse viable borrar físicamente la información, incluso para los comercios más pequeños.

[germonti]

El caso no es cuando un dato ya no es util, sino cuando proviene de un error de carga. Es decir el dato que se grabó no debio estar nunca en ese lugar. COn respecto a tu comentario, tambien se habló, es decir mantener la consistencia de los datos, pero surgio otra duda, si eliminar un registro en una tabla para ponerla en otra es borrar o no es borrar, es decir es una acción fisica de borrado, para luego volver a la diferencia de dato y registro. Es valido pasar un registro de una tabla a otra, para hacer DM DW o simple backup, por ejemplo al finalizar el año fiscal. Pero de ese dato que se movio, el registro ¿Debe eliminarse de la tabla original? Viendo como planteas el problema me interesa tu opinion. Gracias

[sakurama23]

nice topic~~~

[gnzsoloyo]

El caso no es cuando un dato ya no es util, sino cuando proviene de un error de carga.

"...si un programa genera un error, deberá ser documentado. "
Murphy dixit...

Este es el caso que cae bajo la órbita de la administración de la base, y tiene que ver con decisiones propias del papel. No es posible hacer una afirmación taxativa precisamente porque dependerá del caso.
De todos modos, el problema de una entrada errónea es tanto un problema de programación como de diseño de base de datos: Una entrada errónea, un dato erróneo o inválido, simplemente no debería existir, por lo que no debe permanecer en la base en tanto dato no válido.
Ahora bien, si el dato en cuestión ya está integrando algún tipo de reporte o análisis, es decir, si ya hay información generada con él, el sistema se vuelve dependiente de su existencia, y eliminarlo generará inconsistencias que solamente pueden salvarse o regenerando todo (demasiado costo) o manteniéndolo y haciendo las erratas necesarias.
En ese contexto, el registro erróneo podrá mantenerse si y sólo si existe alguna forma de dependencia.
De todos modos, como verás, pasa a ser una decisión de nivel más alto en la empresa.

[germonti]

Gracias nuevamente por su participación, para mi el tema esta cerrado.