Rodrigo Fuentealba <[EMAIL PROTECTED]> wrote: > El 30/09/06, Alvaro Herrera<[EMAIL PROTECTED]> escribió: > > Rodrigo Fuentealba escribió: > > > 2006/9/30, Percy Gonzales <[EMAIL PROTECTED]>: > > > [...] > > > >La aplicacion en todos los casos es la misma > > > > > > entonces los perejiles tienen que mantener una sola base de datos, con > > > un buen cluster, le ponen un buen esquema de respaldos y una VPN para > > > que los clientes usen la BD vÃa Internet de forma (más o menos) > > > segura. (obviamente hay que pensar en asegurar todo). Si van a hacer > > > eso, btw, van a necesitar conexiones y todo de harta más potencia. > > > > Uff, eso suena un esquema extremadamente complejo y fragil
> Bueno, asà es como lo habrÃa hecho yo (dije que no era el más indicado > en responder... a mà dejenme los modelos de datos no más). De todas > maneras estamos de acuerdo en que no hay que mantener varias copias de > la base de datos porque se "des-sincronizan" mucho. En resumen, mejor > un espejo (pero geográficamente distante). O segmentar de alguna forma, o sea, las transacciones de cada lugar se manejan alli (posiblemente remotamente). > > Mucho > > mejor es tener un sistema distribuido, en el cual cada sucursal tiene > > una copia local de la BD y se utiliza un esquema para mantener > > sincronizado esa con la central. Eso es horrible de manejar desde el punto de consistencia (que si en A restan 100 de la cuenta, y en B le suman 20? cual de los resultados vale?) > ¿Replicando al momento, ejecutando una consulta entre varios servers, es > decir? Algo asi... Nada divertido. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513