c# - Con MS Sync Framework 2.0, ¿cómo puedo manejar mejor las tablas relacionadas?

.net synchronization (6)

Sync Framework sincroniza los datos mesa por tabla, pero mis entidades se normalizan en conjuntos de tablas padre-hijo relacionadas. Esto crea problemas para mi aplicación donde una fila principal puede aparecer en el servidor para ser procesada, pero las filas secundarias pueden no aparecer por unos segundos. Si hay un problema de conexión entre mi aplicación cliente y el servidor, es posible que las filas secundarias no aparezcan durante un tiempo.

¿Cómo puedo diseñar mi aplicación para manejar las tablas secundarias sincronizadas por separado de las tablas padre?

El escenario específico que estoy viendo es recibir órdenes de trabajo en un servidor desde un sistema de backend para ser distribuidas a los ingenieros en el campo usando tabletas o PDA. Estas órdenes de trabajo son entidades grandes y complejas que pueden cubrir media docena de tablas. Los ingenieros completan su trabajo, sincronizan los resultados y el servidor devuelve la orden de trabajo completada al sistema de back-end.

Algunas de mis ideas hasta ahora se publican a continuación.

Diseña la aplicación para que no importe si los datos aparecen en momentos diferentes. La aplicación mostrará u operará con los datos disponibles en ese momento. Si aparecen más datos más tarde, se mostrará también.

Pros:

Esta podría ser una forma flexible y robusta de manejar datos y no depende de muchos códigos de sincronización complicados.

Contras:

Puede ser confuso para el usuario si cree que está viendo una tarea completa, o una orden de trabajo, o lo que sea, pero las piezas adicionales aparecen más adelante.
Si los datos sincronizados de un usuario al servidor se envían a otro sistema de back-end, es posible que ese sistema no admita envíos parciales.

Usando Sync Framework, agregue las tablas relacionadas en sus propios grupos de sincronización. Por ejemplo, agregar tablas OrderHeader y OrderDetail a su propio grupo de sincronización llamado Pedidos.

No coloque nada más en un grupo de sincronización a menos que esté directamente relacionado.

Luego sincronice cada uno de los grupos de sincronización en una transacción. De esta forma, tiene la garantía de sincronizar ambas o ninguna de las tablas ...

Por favor, pregunte si necesita más detalles sobre este proceso.

¿Qué tal algo con sumas de comprobación? Cada vez que la aplicación realiza un cambio en la entidad, calcula un hash basado en los últimos contenidos de la entidad y lo guarda en la fila principal. Cuando la aplicación lee la entidad, puede volver a calcular el hash. Si los datos que están disponibles en el momento no coinciden con el hash almacenado con la entidad, la aplicación sabe que hay más sincronización por hacer.

Pros:

Podría ser un cambio bastante directo al modelo de dominio de la aplicación que no implica el cambio de las partes internas de Sync Framework.

Contras:

La aplicación necesitaría leer todas las filas que se relacionan con la entidad en la memoria cada vez que realice un cambio.
Esto se volvería mucho más complicado si la aplicación tuviera que admitir actualizaciones para la misma entidad provenientes de múltiples clientes.
Es necesario planificar cuidadosamente qué cambios se sincronizan en cada dirección y cuándo se calcula el hash correspondiente. Dependiendo de sus datos, es posible que deba sincronizar las mismas tablas varias veces.
A medida de una aplicación; no podría tomar el mismo código y aplicarlo a otra cosa.

Desnormalizar todo Cree una vista de base de datos que aplana las tablas relacionadas en un solo conjunto de resultados, o simplemente almacene sus datos en una tabla grande en primer lugar. Configure Sync Framework para sincronizar esa única tabla, combinándola con la tecla "más a la izquierda" de la vista, que debería ser la clave principal de la tabla raíz en la jerarquía. Cada transacción en el cliente ahora consta de todos los cambios realizados en una sola entidad.

Pros:

Puede implementarse completamente en la base de datos.
No es necesario reemplazar ninguna parte del Marco de Sincronización.
Puede escalar bastante bien a grandes cantidades de filas siempre que tenga cuidado sobre cómo se construyó y se filtró la vista, y cómo se indexaron las tablas subyacentes.

Contras:

Lanzar la normalización de la base de datos podría considerarse malo.
Puede que no se adapte bien a un gran número de tablas y columnas, lo que requiere muchas combinaciones.
También debe agregar los datos de seguimiento de cambios.
Si usa una vista, debe crear activadores para que sea actualizable.

Pude personalizar Sync Framework para que respetara las relaciones con las bases de datos. Cuando un SyncAdapter personalizado aparece en una fila con cambios, podría atravesar las relaciones secundarias en el esquema de la base de datos para detectar cualquier cambio en las filas relacionadas. Todos estos cambios se agregarán al mismo conjunto de datos y se sincronizarán como una sola transacción.

Pros:

Esta parece ser la mejor solución desde la perspectiva de la integridad de los datos. Puedo estar seguro de que una entidad en particular contiene todos los cambios disponibles de un cliente, o ninguno de ellos.
No necesito cambiar mis entidades o describirlas de manera especial al adaptador personalizado; toda la información que necesita se puede derivar para las relaciones de bases de datos que ya tengo.
No necesito hacer nada especial con mi esquema de base de datos: puedo apuntar mi código casi en cualquier base de datos y simplemente funcionará.

Contras:

Personalizar el Sync Framework de esta manera podría ser mucho trabajo y requeriría un conocimiento detallado de las funciones internas del framework.
El adaptador personalizado necesitaría detectar y manejar relaciones de bases de datos circulares.

No hay suficiente espacio dentro del cuadro de comentarios para mis pensamientos:

Sincronizar entidades maestras en lugar de datos relacionales? No sé si podemos hacer eso con Sync Framework ... ¿quizás implementar un proveedor personalizado?

Todavía hay un problema con las transacciones. Tomemos una muestra tonta, usted tiene cuentas, cada cuenta es una entidad maestra.

Base de datos A

BeginTransaction Substract $500 from account 1 Add $200 to account 2 Add $300 to account 3 EndTransaction

Base de datos B

BeginTransaction Substract $100 from account 1 Add $100 to account 4 EndTransaction

Cuando sincronice, detectará un conflicto en 1 pero no en 2, 3 y 4. Con esta muestra puede elaborar una estrategia de fusión, pero ese no es siempre el caso.