> mmm... a menos que las informaciones sean distintas (ejemplo, material > en producción en Rancagua y gestión de clientes en Santiago), yo > optaría por centralizar primero y replicar en las distintas sucursales > (utilizándolas como nodos de respaldo geográficamente distantes en > caso de desastres...) >
Actulmente trabaja asi, cada sucursal accede a su servidor local, pero resulta que cuando la gente de la of. principal desea acceder a informacion actulizada de esa oficina o bin debe acceder en ese momento a ese servidor o bin esperar que el db centralice la BD principal. La aplicacion en todos los casos es la misma, solo que accede en cada caso a su BD local y enel caso de la of. principal accede a todas si desean tener los datos actualizados al momento sin tener que esperar la centralizacion. > Hay que ser muy... para dejar una base de datos dispersa (porque me > imagino que no está distribuida, con lo que cuentas... más pega pa él, > más ineficiente, etc.) > Depende, ¿en qué lenguaje está hecha la aplicación? Si es alguna > lesera como .NET (porque hablaste solamente de la base de datos, pero > no de la app) podrían haber usado servicios web XML para sincronizar > la información en varias bases a la vez... aunque a la gente aqui no > le guste (me incluyo). El cliente que se utiliza esta hecho en forms y reports que son productos de oracle, es muy poco probable que se opte por cambiar la aplicacion o tendria que pasar bastante tiempo en desarrollar otra con tecnologia web. > > En este caso sera mejor utilizar centralizacion, replicacion, BD > > distribuidas, u otra? Tengo entendido que existen diferentes tipos de replicacion (en linea o por cada transaccion, por demanda o cada ciertotiempo o cada cierta cantidad de transacciones), y tambien BD distribuidas, para este escenario cual seria la mas recomendable.