¿La mejor tecnología para sincronizar datos entre diferentes esquemas de bases de datos?

Question

Tengo una base de datos SQL Server 2005 que ejecuta nuestra aplicación de contabilidad/inventario. Estamos estudiando el uso de un nuevo marco de pedidos en línea, que tiene su propia base de datos.

Si usamos este nuevo marco, tendremos que transferir los datos de pedidos en línea (inventario, precios, pedidos, clientes) casi en tiempo real desde y hacia nuestra base de datos de inventario existente. La transferencia de datos no tiene que ser en tiempo real, pero tiene que ser rápida. Ambas bases de datos estarán en SQL Server.

Así que mi pregunta es ... ¿cuál es la mejor forma de transferir datos entre dos bases de datos, con diferentes esquemas?

¿Replicación? SSIS? ¿Qué sugerirías y por qué?

¡Cualquier ayuda sería apreciada!

Answer 1

Personalmente huiría de esta pesadilla lo más rápido que pudiera. Dado que aún no ha comprado este pedido en línea, sugeriría que mantener los datos sincronizados con la aplicación existente es una razón válida para no hacer tal cosa. Si compras esto, te arrepentirás eternamente de lo malgastado que se convertirán tus datos y de cuánto tiempo y dinero gastas tratando de hacer que las cosas funcionen correctamente. Este es un desastre esperando a suceder. Al final, tendrás personas que piden artículos supuestamente en iventory cuando no hay ninguno en el almacén. No hagas esto. Esta es una garantía de clientes enojados y gerentes enojados. Con el tiempo, es mucho más barato contratar a algunos desarrolladores para armar sus propios pedidos en línea que acceden a su base de datos. Si continúan con sus objeciones, actualizaría mi currículum.

Answer 2

replicación funciona bien, y si se trata de dos vías, que podría ser su única opción viable, ya que la resolución de conflictos está integrada.

Si usted va en un solo sentido, SSIS o desencadena en las mesas sería muy bien, y empujaría los datos en tiempo real (para desencadenantes) o al intervalo que desee (SSIS). Lo bueno de SSIS sería que se trata de un proceso en segundo plano, mientras que los desencadenantes podrían retrasar las transacciones por el lado de la oferta mientras empujan los datos.

Si está buscando mover grandes cantidades de datos, existen otros productos que pueden hacerlo por usted, pero si no son demasiados datos, una solución que use las herramientas Servidores SQL debería hacer todo lo que necesita.

Answer 3

Por experiencia personal, solo usaría replicación si no hubiera otra opción. Tienes que derribarlo para cualquier cambio de esquema y tiene una tendencia a explotar.

Para esto, lo más probable es que use SSIS. Es bastante fácil construir un paquete de transformación y bastante fácil de mantener.

Answer 4

las reglas de negocio son la parte más difícil

sincronización unidireccional? Sincronización bidireccional Empuje en tiempo real? Actualizaciones nocturnas ¿Volcar y recargar? Comparar y actualizar? ¿La resolución de conflictos? ¿Qué lado gana? ¿Empuja la información de solo lectura de una manera y ordena la información a la inversa? ¿Qué pasa con cambios/cancelaciones/etc.? ¿Los estados de los pedidos son rechazados?

Puedes ver a dónde voy. La tecnología es una pregunta secundaria.

Debido a la cuestión de reglas comerciales, y debido a que los dos sistemas tienen diferentes esquemas (y diferentes propósitos), esto no es un movimiento de datos estándar, y la mayoría de las respuestas "estándar" (replicación, envío de registros, etc.) están fuera de la mesa.

Existen marcos diseñados para ayudar con esto, como Microsoft BizTalk o Scribe Insight. Sin embargo, estos son engorrosos y caros.

No es demasiado difícil crear un sistema de colas personalizado basado en activadores de SQL o impulsos programados (según sus necesidades) en C# o en su idioma favorito. Esa es probablemente la ruta que iría. Probablemente implicaría una tercera base de datos de "transferencia" para contener la cola de cambios realizados por un lado y un módulo para aplicar las reglas comerciales y enviar los datos al otro.