database-design - para - manual de programacion android pdf

¿Cuál es la mejor manera de almacenar los cambios en los registros de la base de datos que requieren aprobación antes de ser visibles? (8)

Como se trata de una aplicación web, supongo que hay más lecturas que escrituras, y desea algo razonablemente rápido, y la resolución de conflictos (es decir, las aprobaciones fuera de servicio) da como resultado el mismo comportamiento: la última actualización es la que es usado.

Ambas estrategias que propone son similares, ya que ambas tienen una fila por conjunto de cambios, tienen que lidiar con conflictos, etc., la única diferencia es si almacenar los datos en una tabla o dos. Dado el escenario, dos tablas parecen la mejor solución por razones de rendimiento. También puede resolver esto con una tabla y una vista de los cambios aprobados más recientes si su base de datos lo admite.

Necesito almacenar los cambios introducidos por el usuario en una tabla en particular, pero no mostrar esos cambios hasta que hayan sido vistos y aprobados por un usuario administrativo. Si bien esos cambios todavía están en un estado pendiente, aún mostraría la versión anterior de los datos. ¿Cuál sería la mejor manera de almacenar estos cambios esperando su aprobación?

He pensado en varias maneras, pero no puedo entender cuál es el mejor método. Esta es una aplicación web muy pequeña. Una forma sería tener una tabla PendingChanges que imite el esquema de la otra tabla, y luego, una vez que se apruebe el cambio, podría actualizar la tabla real con la información. Otro enfoque sería hacer algún tipo de versión de registro donde almaceno múltiples versiones de los datos en la tabla y luego siempre extraer el registro con el número de versión más alto que haya sido marcado como aprobado. Eso limitaría el número de tablas adicionales (tengo que hacer esto para múltiples tablas), pero requeriría que haga un procesamiento adicional cada vez que saque un conjunto de registros para asegurarme de obtener los correctos.

¿Alguna experiencia personal con estos métodos u otros que podrían ser buenos?

Actualización: Solo para aclarar, en esta situación particular, no me interesan demasiado los datos históricos. Solo necesito una forma de aprobar cualquier cambio que realice un usuario antes de que se publique en el sitio. Entonces, un usuario editará su "perfil" y luego un administrador verá esa modificación y la aprobará. Una vez aprobado, se convertirá en el valor mostrado y no es necesario conservar la versión anterior.

¿Alguien probó la solución a continuación donde almacena los cambios pendientes de cualquier tabla que necesita rastrearlos como XML en una tabla especial PendingChanges? Cada registro tendría una columna que dijera para qué tabla eran los cambios, una columna que tal vez almacenara la identificación del registro que se cambiaría (nulo si es un registro nuevo), una columna de fecha y hora para almacenar cuando se realizó el cambio, y una columna para almacenar el xml del registro modificado (podría tal vez serializar mi objeto de datos). Como no necesito historial, después de aprobar un cambio, la tabla real se actualizaría y el registro de PendingChange podría eliminarse.

¿Alguna idea sobre ese método?

Crearía una tabla con una bandera y crearía una vista como

CREATE OR REPLACE VIEW AS SELECT * FROM my_table where approved = 1

Puede ayudar a separar las dependencias entre la aprobación y las consultas. Pero puede que no sea la mejor idea si es necesario realizar actualizaciones a la vista.

Mover registros puede tener algunas consideraciones de rendimiento. Pero las tablas Partitioned podrían hacer algo bastante similar.

Creo que la segunda forma es el mejor enfoque, simplemente porque se adapta mejor a varias tablas. Además, el procesamiento adicional sería mínimo, ya que puede crear un índice en la tabla basado en el bit ''aprobado'', y puede especializar sus consultas para obtener entradas aprobadas (para ver) o no aprobadas (para aprobar).

Dado el movimiento de cumplimiento de SOx que se ha visto empujado por la mayoría de las empresas que cotizan en bolsa, he tenido bastante experiencia en esta área. Usualmente he estado usando una tabla separada con una marca de tiempo de cambios pendientes con algún tipo de columna de bandera. La persona a cargo de la administración de estos datos obtiene una lista de cambios pendientes y puede optar por aceptar o no aceptar. Cuando se acepta una pieza de datos, uso disparadores para integrar los nuevos datos en la tabla. Aunque a algunas personas no les gusta el método desencadenante y prefieren codificarlo en los procesos almacenados. Esto me ha funcionado bien, incluso en bases de datos bastante grandes. La complejidad puede ser un poco difícil de tratar, especialmente cuando se trata de una situación en la que un cambio entra directamente en conflicto con otro cambio y en qué orden procesar estos cambios. La tabla que contiene los datos de solicitud nunca podrá borrarse, ya que contiene las "migas de pan", por así decirlo, que son necesarias en caso de que sea necesario rastrear lo sucedido en una situación particular. Pero en cualquier enfoque, se deben evaluar los riesgos, como lo que mencioné con los datos conflictivos, y se necesita una capa de lógica de negocios para determinar el proceso en estas situaciones.

Personalmente, no me gusta el mismo método de tabla, porque en los casos de almacenes de datos que se cambian constantemente, estos datos adicionales en una tabla pueden empantanar innecesariamente la solicitud en la tabla, y requerirían mucho más detalles sobre cómo están indexando la tabla y sus planes de ejecución.

Definitivamente almacenarlos en la tabla principal con una columna para indicar si los datos están aprobados o no.

Cuando se aprueba el cambio, no se requiere copiar. El trabajo adicional para filtrar los datos no aprobados es el tipo de cosa que las bases de datos deben hacer, cuando lo piensas. Si indexa la columna aprobada, no debería ser demasiado oneroso para hacer lo correcto.

El tamaño es tu enemigo. Si se trata de una gran cantidad de datos y un gran número de filas, mezclar el histórico con la corriente lo martillará. También tendrá problemas si se une a otros datos para asegurarse de tener las filas correctas.

Si necesita guardar los datos históricos para mostrar los cambios a lo largo del tiempo, iría con la tabla histórica independiente, que actualiza los datos reales en vivo una vez que se aprueba. Es solo un limpiador general.

Si tiene muchos tipos de datos que tendrán este mecanismo pero no necesitan mantener un registro histórico, sugeriría un talbe de cola común para revisar los artículos pendientes, por ejemplo, almacenados como xml. Esto permitiría que los administradores solo lean una tabla y le permitirá agregar esta funcionalidad a cualquier tabla en su sistema con bastante facilidad.

Otra idea más sería tener tres tablas.

Una sería la tabla principal para contener los datos originales.
El segundo contendría los datos propuestos.
El tercero mantendría los datos históricos.

Este enfoque le brinda la capacidad de retroceder rápida y fácilmente y también le proporciona un seguimiento de auditoría si lo necesita.

Trabajo en un dominio bancario y tenemos esta necesidad: que los cambios realizados por un usuario solo deben reflejarse después de ser aprobados por otro. El diseño que usamos es el siguiente

Tabla principal A
Otra Tabla B que almacena el registro modificado (y es exactamente similar al primero) + 2 columnas adicionales (una FKey a C y un código para indicar el tipo de cambio)
Una tercera tabla C que almacena todos los registros que necesitan aprobación
Una cuarta tabla D que almacena el historial (probablemente no lo necesite).

Recomiendo este enfoque. Maneja todos los escenarios, incluidas las actualizaciones y eliminaciones de forma muy elegante.