sql server - vista - ¿La mejor tecnología para sincronizar datos entre diferentes esquemas de bases de datos?
replicacion de base de datos sql server 2012 (4)
Tengo una base de datos SQL Server 2005 existente 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 utilizamos este nuevo marco, necesitaremos 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.
Entonces mi pregunta es ... ¿cuál es la mejor manera 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!
La replicación funciona bien, y si es bidireccional, podría ser la única opción viable, ya que la resolución de conflictos está integrada.
Si va en un solo sentido, SSIS o desencadenantes en las tablas estarían 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.
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.
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.
Las reglas de negocios son la parte 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 aquí. La tecnología es una pregunta secundaria.
Debido al problema de las reglas comerciales, y debido a que los dos sistemas tienen diferentes esquemas (y diferentes propósitos), este 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 cola personalizada basado en activadores de SQL o en intentos 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 mantener la cola de los cambios realizados por un lado, y un módulo para aplicar las reglas comerciales y enviar los datos al otro.