centralizacion de BD
Rodrigo Fuentealba
darkprox en gmail.com
Dom Oct 1 01:39:01 CLT 2006
> > 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).
Horst Von Brand:
> O segmentar de alguna forma, o sea, las transacciones de cada lugar se
> manejan alli (posiblemente remotamente).
Alvaro Herrera:
> > > 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.
HvB:
> 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?)
Correcto, por eso mismo decía que era mejor mantener una sola base de
datos. INACAP lo hace de esa forma, concentrando todos sus datos en
una ubicación específica (el bunker), y con 26 sedes y teniendo a
todos sus alumnos y todas las notas, consultas, plataforma, etc... yo
creo que tienen bastantes datos.
Hay que planificar tomando más en cuenta la consistencia de los datos
(algo que se maneja a cada segundo) que si se interrumpe el servicio
de red (una vez cada tres meses, quizá?)
Otra forma (muy facil pero mala según yo, reten al profe que me dio la
idea, no a mí) es que cada sucursal tenga sus propios datos
(incluyendo la central), y que los reportes de datos se generen allá y
se envíen vía e-mail. No hay fallas de carga, no hay fallas de
conexión entre sucursales y la matriz, pero no hay un control
constante (algo que a los gerentes les gusta mucho) y hay que hacer
mantenimiento a demasiados servidores. En resumen, nada entrete.
--
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org
Más información sobre la lista de distribución Linux