Asesoramiento sobre particionamiento base de datos

Yo optaría por añadir una columna IdDelegación (que entraría a formar parte
de la clave) a cada tabla y almacenar los datos en la sede central con los
mismos nombres de tabla que las originales. A continuación (suponiendo que
la sede central no actualiza ni inserta a menudo y que la mayoría de los
datos se generan en las delegaciones) configuraría replicaciones
transaccionales con actualizaciones en cola (o incluso replicacion de
mezcla) particionando los datos por la nueva columna IdDelegación para que
cada suscriptor sólo reciba SUS propios datos. Con esto tendrías la ventaja
de que cada delegación seguiría atacando a su servidor SQL local (no
notarían ningún tipo de cambio en el rendimiento, si todo se configura bien)
con la ventaja añadida de que en la sede central tendríais la visión de
conjunto con todos los datos de todas las delegaciones en N tablas y no en
17 * N tablas diferentes, con el prefijo de delegación como sugieres.

Por supuesto no es algo que puedas poner en funcionamiento en 5 minutos.
Necesitarás estudiarlo bastante, e incluso montarte un entorno (lo mas
barato sería virtualizado) de pruebas para ver como se comportaría todo el
sistema.

J.A. García Barceló
http://jagbarcelo.blogspot.com/
Seguro que a alguien más se le ocurre algo... yo también quiero aprender :)


"Joaquin Pelayo Bedia" <joapel??@terra.es> escribió en el mensaje
news:

Hola.

La consulta es la siguiente, nuestra empresa tiene una sede central y 17
delegaciones. Cada delegacion en la actualidad tiene su propia base de
datos
en SQL Server ya que todas tienen la misma estructura en lo que a datos se
refiere. Me estoy planteando unificar todas las bddb en una sola,
anteponiendo al nombre la de tabla el nombre de la degacion.

Se me plantean muchas dudas como por ejemplo , si el rendimiento de las
aplicaciones caerá al estar todos los usuarios conectados a la misma
bbdd???, Que experiencia tenéis y que me recomendáis????

Muchas gracias.

Joaquin Pelayo Bedia