database - inventor - Base de datos: para borrar o eliminar registros

guardar datos en app inventor (8)

Como complemento de todas las publicaciones ...

Sin embargo, si planea marcar el registro, es bueno considerar hacer una vista, para registros activos. Esto le evitaría escribir u olvidar el indicador en su consulta SQL. También podría considerar una vista para registros no activos, si cree que eso también tiene un propósito.

No creo ser la única persona que se pregunta sobre esto. ¿Qué usualmente practicas sobre el comportamiento de la base de datos? ¿Prefiere borrar físicamente un registro de la base de datos? ¿O es mejor simplemente marcar el registro con una bandera "eliminada" o una columna booleana para indicar que el registro está activo o inactivo?

Definitivamente depende del contenido real de su base de datos. Si lo está usando para almacenar información de sesión, entonces, por supuesto, límpielo inmediatamente cuando la sesión caduque (o se cierre), no querrá que esa basura se desperdicie. Como no puede ser usado de nuevo para ningún propósito práctico.

Básicamente, lo que debe preguntarse a sí mismo, ¿podría necesitar restaurar esta información? Al igual que las preguntas eliminadas en SO, definitivamente deberían marcarse como "eliminadas", ya que estamos permitiendo activamente una recuperación. También tenemos la opción de mostrarlo para seleccionar usuarios también, sin mucho trabajo adicional.

Si no está buscando activamente restaurar completamente los datos, pero aún desea mantenerlos para fines de monitoreo (o similares). Sugeriría que averigües (en la medida de lo posible, por supuesto) un esquema de agregación y que lo pases a otra mesa. Esto mantendrá su tabla primaria limpia de datos ''eliminados'', así como también mantendrá su tabla secundaria optimizada para fines de monitoreo (o lo que sea que tenga en mente).

Para datos temporales, ver: http://talentedmonkeys.wordpress.com/2010/05/15/temporal-data-in-a-relational-database/

En el caso de los datos ingresados / administrados por el usuario, utilicé el método de indicador que describes y le di al usuario una interfaz de "vacío de la papelera" para eliminar los elementos si así lo desea.

Estoy contento de haber encontrado este hilo. Yo también me preguntaba qué pensaba la gente sobre este tema. Implementé el ''marcado como eliminado'' durante aproximadamente 15 años en muchos sistemas. Cada vez que un usuario llamaba para decir que se borró accidentalmente algo, era mucho más fácil marcarlo como no eliminado que recrearlo o restaurarlo desde una copia de seguridad.

Estamos usando postgresql y Ruby on rails, parece que podríamos hacer esto en una de dos formas, modificar los raíles o agregar un desencadenador ondelete y en su lugar una función pl / pgsql para marcar como eliminado. Me estoy inclinando hacia este último.

En cuanto a éxitos de rendimiento, será interesante ver los resultados de EXPLAIN-ANALYZE en tablas grandes con pocos elementos eliminados, así como muchos elementos eliminados.

En los sistemas utilizados a lo largo del tiempo que he encontrado, los usuarios nuevos tienden a hacer cosas tontas como eliminar cosas accidentalmente. Entonces, cuando las personas son nuevas en un puesto, tienen todos los derechos de acceso de la persona que estaba anteriormente en ese puesto, excepto que no tienen experiencia. Eliminar accidentalmente algo y poder recuperarse rápidamente hace que todos vuelvan a trabajar rápidamente.

Pero como alguien dijo, a veces puede que necesite recuperar esa clave en particular por algún motivo, en ese momento tendría que eliminarla realmente, luego volver a crear los registros (al recuperarla y modificar el registro).

Los marcó como eliminados, y realmente no los borro. Sin embargo, de vez en cuando elimino toda la basura y la archivé, por lo que no mata el rendimiento.

Si le preocupan los registros "inactivos" que ralentizan el acceso a la base de datos, puede mover esas filas a otra tabla que actúa como una tabla de "archivo".

También existen problemas legales de cualquier forma si se trata de datos personales. Creo que depende mucho de dónde se encuentre (o dónde esté la base de datos) y cuáles son los términos de uso.

En algunos casos, las personas pueden solicitar ser removidas de su sistema, en cuyo caso se necesita una eliminación definitiva (o al menos borrar toda la información personal).

Verificaría con su departamento legal antes de adoptar una estrategia de cualquier manera si se trata de información personal.

Ventajas de usar una bandera de eliminación:

Puede recuperar los datos más tarde si lo necesita,
La operación de eliminación (actualizar el indicador) es probablemente más rápida que realmente eliminarla

Contras de usar una bandera de eliminación:

Es muy fácil perder AND DeletedFlag = ''N'' en algún lugar de su SQL
Más lento para la base de datos para encontrar las filas que le interesan entre toda la basura
Eventualmente, probablemente quieras eliminarlo de todos modos (suponiendo que tu sistema sea exitoso. ¿Qué ocurre cuando ese registro tiene 10 años y fue "eliminado" 4 minutos después de haber sido creado originalmente)?
Puede hacer que sea imposible usar una clave natural. Puede tener una o más filas borradas con la clave natural y una fila real que quiera usar esa misma clave natural.
Puede haber razones legales / de cumplimiento por las cuales debe eliminar los datos.