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

Question

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 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.

Answer 1

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

No pongas 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 manera, se garantiza que sincronizarán ambas o ninguna de las tablas ...

Solicite más detalles sobre este proceso.

Answer 2

Podría personalizar Sync Framework para que respete las relaciones con la base 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:

• esto parece la mejor solución desde el punto de vista 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 ni describirlas de ninguna 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 en cualquier base de datos y simplemente funcionará.

Contras:

• la personalización de la Sync Framework esta manera podría ser un montón de trabajo y requeriría un conocimiento detallado de los componentes internos del marco.
• El adaptador personalizado necesitaría detectar y manejar relaciones de bases de datos circulares.

Answer 3

Diseñe la aplicación de modo 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:

• Esto podría ser una manera flexible y robusta de tratar con datos y no depender de una gran cantidad de código de sincronización complicada.

Contras:

• Podría ser confuso para el usuario si piensan que están viendo una tarea completa, u orden de trabajo, o lo que sea, pero las piezas adicionales aparecen más adelante.
• Si los datos se sincronizan de un usuario al servidor para ser enviados a algún otro sistema de back-end, ese sistema podría no admitir envíos parciales.

Answer 4

¿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 sencillo modelo de dominio de la aplicación que no implique el cambio de partes internas de Sync Framework.

Contras:

• La aplicación tendría que leer todas las filas que se relacionan con la entidad en la memoria cada vez que se hace un cambio.
• Esto se volvería mucho más complicado si la aplicación tuviera que soportar actualizaciones a 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 la medida de una aplicación; no podría tomar el mismo código y aplicarlo a otra cosa.

Answer 5

Denormalizar 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:

• se puede implementar en su totalidad en la base de datos.
• No es necesario reemplazar ninguna parte del Marco de sincronización.
• Se puede escalar bastante bien a un gran número de filas siempre que tenga cuidado acerca de cómo se construyó y se filtró la vista, y cómo se indexaron las tablas subyacentes.

Contras:

• Tirar la normalización de bases de datos podría ser considerado malo.
• Puede que no se adapte bien a un gran número de tablas y columnas, lo que requiere muchas combinaciones.
• Tiene que agregar los datos de seguimiento de cambios también.
• Si utiliza una vista, tiene que crear activadores para que sea actualizable.

Answer 6

No hay suficiente espacio en el interior de la caja de comentarios de mis pensamientos:

entidades maestras Sincronizar en lugar de datos relacionales? No sé si podemos hacer eso con Sync Framework ... ¿quizás implementando 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 Un

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 

Al sincronizar, se detecta un conflicto en 1, pero no los días 2, 3 y 4. Con esta muestra se puede elaborar una combinación estrategia, pero ese no es siempre el caso.