Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > Firebird e Interbase
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

 
 
Herramientas Buscar en Tema Desplegado
  #20  
Antiguo 18-03-2010
Avatar de guillotmarc
guillotmarc guillotmarc is offline
Miembro
 
Registrado: may 2003
Ubicación: Huelva
Posts: 2.638
Poder: 25
guillotmarc Va por buen camino
Hola Casimiro.

Cita:
Empezado por Casimiro Notevi Ver Mensaje
Muy interesante lo que me cuentas, aunque, como siempre, cada caso es un mundo .
El caso que cuentas de cadetill y supongo que el tuyo, son muy particulares, por ejemplo el de las farmacias sólo será sincronizar las medicinas que se venden y hacer pedidos de las que necesiten. Las farmacias no llevan (normalmente ) clientes, almacenes, bancos, etc. O sea, que seguramente la replicación es sólo de algunas tablas porque las otras no serán necesarias o tendrán un movimiento mínimo (supongo).
En mi caso es más complejo porque sería actualizar/replicar toda la base de datos... que ahora mismo tiene 263 tablas y además campos blob con imágenes y documentos muy variados. Algunos de nuestros clientes han pasado los 20 Gb y eso por internet... :S
En realidad lo hemos probado con un cluster Heartbeat por internet y era morirse de pena (en red local va bien), pero si pudiésemos limitarnos a sólamente los artículos, clientes y poco más... entonces sí sería una buena opción la replicación que comentas.
En nuestro caso ni los representantes pueden vender con precios "de ayer", necesitan tener el precio y el stok "ahora mismo", como si estuviesen en la central, así que también llevan conexión a la central y trabajan al igual que las sucursales, todos contra el servidor central.
De todas formas, está muy interesante el sistema de replicación que comentas para según que negocios.
Es cierto que con un sistema de replicación nunca tienes datos garantizados, no sabes cuan buenos pueden ser. Por eso para montar el sistema que comentas habría que complementarlo con otro sistema.

Es decir, en un caso como el vuestro, yo quizás montaría igualmente el sistema de replicación, pero para los datos críticos, donde se necesite la información exacta en la central (como precios o stock), montaría un WebService, de forma que esos datos se consulten directamente a la central.

Pero el resto se puede replicar perfectamente.

Mi aplicación consta de 131 tablas, que se replican todas, y en el caso del cliente con 15 tiendas, en estos momentos tiene 900Mb de tamaño (no incluye imágenes, documentos, etc. ..., todo es pura información).

Aunque está lejos de los 20Gb., para el caso creo que es lo mismo. Puesto que como te puedes imaginar, tampoco pasamos nunca esos 900Mb por Internet, excepto cuando se corrompe la base de datos en una tienda, o bien cuando se monta una tienda nueva, pero en lugar de replicar todos los datos (lo cual sería lentísimo, puesto que haría INSERTS para todos los registros de la Base de Datos), simplemente les envío una copia de la base de datos del servidor central (previamente configurada para actuar como la tienda destino). Esta es otra ventaja del sistema de replicación, ya no necesitan copias de seguridad, puesto que cada tienda es en si misma una copia de seguridad de los datos del resto de tiendas.

Solo se pasan los datos introducidos o modificados desde la última replicación, el tamaño promedio del archivo de datos que se envía cada 10 minutos es de unos 20kb.

En casos donde una tienda ha estado un mes sin replicar debido a cambios en el ADSL o lo que sea, lo más grande que se suele pasar es un archivo del orden de 1Mb (aquí nos caben perfectamente, comprimidos en un zip, los miles de registros que se han introducido durante ese mes).

Claro que como dices, cada caso es un mundo, así que imagino que habrá casos donde el volumen de información que se introduce a diario puede hacer inviable la replicación, pero la verdad es que no creo que sean muchos (quizás en un sistema donde se almacenan muchos archivos binarios grandes, como imágenes, etc. ...).

Piensa que el clúster que montasteis era síncrono (los datos se pasan en tiempo real, ¿ no ?), por eso no tendría un buen rendimiento en Internet. Pero en un sistema de replicación, donde la actualización es asíncrona, no deberías tener esos problemas. El precio que pagas es que la información no está actualizada en tiempo real, pero eso en la inmensa mayoría de tablas no es ningún problema (en el tiempo que tardas llamando a la otra tienda para comentarles que le echen un vistazo al cliente que acabas de añadir, ya habrán pasado unos minutos, y ya lo tendrán disponible).

Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).

Última edición por guillotmarc fecha: 18-03-2010 a las 13:26:28.
Responder Con Cita
 



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Replicación de BD Firebird santiago14 Firebird e Interbase 9 03-10-2017 16:43:55
Replicacion Base de Datos Firebird Rockin Firebird e Interbase 8 03-11-2008 21:48:07
REplicación de Base de datos -TRABAJO ENTRE DISTINTOS MOTORES DE BD- voldemmor Oracle 1 27-05-2007 10:41:23
Herramienta case para diccionario de datos de base de datos firebird mcalmanovici Firebird e Interbase 1 11-02-2007 15:17:37
Replicacion de Base de Datos Mardol SQL 1 02-10-2006 20:38:52


La franja horaria es GMT +2. Ahora son las 18:46:37.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi