Foro de programación

Hola, Guillermo,

estoy de acuerdo con Víctor, sobre todo si os preocupa el rendimiento. No tengo datos exactos pero imagino que para cada base de datos que levante sqlserver consumirá una serie de recursos como por ejemplo el diccionario de datos, si eso lo multiplicas a la fuerza tiene que ser menos óptimo que un idEntidad o un idDelegacion que va a ser un índice.

Está claro que os va a dar más trabajo como dices en las importaciones y exportaciones, porque no sólo va a ser borrar esos datos en la ubicación central, si no borrarlos en el orden correcto por el tema de las claves externas (a no ser que hagais un delete cascade con el riesgo que eso supone), por ejemplo en dos tablas como usuarios y acciones (es un ejemplo) si las acciones son por cada usuario no podreis borrar primero usuarios y luego acciones porque petará, tendreis que hacerlo al revés. Os pasará con muchas tablas seguro. Es mucho más trabajo. Y mantener esos scripts va a ser bastante engorroso, eso o buscais una manera de generar esos scripts de borrado de manera automática en el orden correcto...

Si no he entendido mal el problema es que teneis diferentes sql servers repartidos. Tal como lo estais planteando teneis el problema de que los datos se os queden desfasados entre las delegaciones y centro. ¿Esto es un problema? ¿Cada cuánto vais actualizar unas y otras? ¿Hay cambios en las delegaciones y en centro? Porque si esto es así es más complicado todavía y vais a tener que buscaros un sistema que consolide ambas, no va a ser tan fácil como "machacar" los datos de centro. Si este es el caso yo me plantearía tirar de un solo sql server en "centro", abriendolo para conexiones por http o accediendo a los datos por servicios web.

En fin, no sé si te doy más soluciones o más problemas :P

Un saludo, Gabriel.

Hola Guillermo,

No estoy acostumbrado a trabajar con SQL Server, y no se si funcionará igual que en Oracle, pero en Oracle las tablas, vistas, procedimientos, etc... pertenecen a un usuario.

Si en SQL Server también es así (con usuario, schema o similar), yo te recomendaría crear en una misma base de datos un usuario/schema de Base de Datos para cada delegación, cada uno con sus tablas (iguales o no), y un usuario para las tablas y procedimientos genéricos (tipos, estados, etc...).

Si pasado un tiempo, al tener más delegaciones y todo centralizado, tuvierais problemas de rendimiento, el separar una delegación solo implicaría hacer un backup de los datos del usuario y los datos genéricos e importarlos en otro equipo.

Esta configuración también te permitiría que en caso de querer tener una base de datos por delegación, en la central pudierais tener los datos de las delegaciones en una sola base de datos, importando únicamente los datos de este usuario.

Saludos,

Ricardo

Yo lo haría con una sola BBDD para todo, creando un sistema entidad relación bien estructurado teniendo bien claras cuales son las claves de las tablas así como la relación entre ellas no tendría qeu darte ningún problema.

Nosotros sobre todo trabajamos en Oracle, no SQL Server, pero me parece mejor idea usar una sóla, siempre y cuando todo se haga sobre la misma y no tener distintas versiones de la misma BBDD en cada delegación. Con un sola BBDD para todo, en teoría tendrías la información centralizada y para separarlo por aplicación siempre se pueden hacer esquemas diferentes dentro de la misma BBDD, o lo qeu tenga SQL Server en lugar de esquemas.

En mi ultimo proyecto teniamos el mismo reto arquitectonico y lo solucionamos con una sola base de datos replicada en 12 servidores. Las dos únicas cosas que fueron críticas y que han funcionado perféctamente son:
1. Los indices únicos de los objetos principales del dominio deben evitar duplicidades. En nuestro caso utilizamos el formato codigobase/año/mes/dia/hora/minuto/segundo (año cuatro cifra, el resto dos) y por código evitamos duplicidades controlado errores de FK duplicada y sumando un segundo al id.
2. Mantenemos las bases de datos replicadas entre si con el sistema de replicación del propio slq basado en emisores, replicadores y suscriptores y que funciona muy, muy bien.

Lo único malo es que cualquier cambio en el esquema de datos implica rehacer una instantanea de la base de datos y el tiempo en volverl a sincronizar.

Hay un tema que no comentáis... Y es el tema del precio. Si montáis 200 bases de datos distribuidas, tendréis que pagar 200 licencias.

Yo, personalmente, estudiaría usar cassandra. Así tienes 200 bases de datos autorreplicadas y distribuidas. Nada de anticuados sistemas entidad-relación.

Un saludo.