Ventajas e inconvenientes de un modelo de datos

Hola a todos.

Mi empresa está subdividida por departamentos. Cada departamento crea sus
propios albaranes. Entre ellos no existe ninguna relación; es decir, los
albaranes de un departamento sólo los ve ese departamento. Se crea un

de datos relacional y se propone el siguiente modelo:

a) Todos los departamentos compartirán un mismo servidor.
b) Cada departamento tendrá una base de datos independiente con una

del modelo de datos propuesto.
c) Los datos que sean comunes a todos los departamentos estarán en otra

de datos y serán replicados en cada una de las bases de datos.

La empresa consta de unos 50 departamentos. Se supone que el número de
albaranes crece bastante rápido y de esta forma, se supone que se optimiza
el acceso a ellos. Igualmente cada base de datos trabajará con vistas
particionadas ya que el número de albaranes es demasiado grande.

Mi propuesta es la de hacer que todos los departamentos estén en una misma
base de datos. Con esto creo que el modelo será más puro, más escalable y
óptimo. Es cierto que las tablas particionadas de albaranes serán 50 veces
más grandes pero no creo que sea ese problema para SQL Server.

Se supone que habrá unos 180 usuarios accediendo al servidor. En mi

se achaca que el rendimiento de SQL Server bajará si todos los usuarios
acceden a una misma base de datos, e incluso, a una misma vista. Yo creo

no es así, que el rendimiento del servidor no depende de "donde" accedas.
Cabe decir que no se hacen bloqueos de tablas ni de registros ( no es
necesario ) así que, no puede darse el caso de quedar todo "colgado".

¿Cuál os parece más acertado y por qué?

Gracias a todos


Xavi

Hola a todos.

Mi empresa está subdividida por departamentos. Cada departamento crea sus
propios albaranes. Entre ellos no existe ninguna relación; es decir, los
albaranes de un departamento sólo los ve ese departamento. Se crea un

de datos relacional y se propone el siguiente modelo:

a) Todos los departamentos compartirán un mismo servidor.
b) Cada departamento tendrá una base de datos independiente con una

del modelo de datos propuesto.
c) Los datos que sean comunes a todos los departamentos estarán en otra

de datos y serán replicados en cada una de las bases de datos.

La empresa consta de unos 50 departamentos. Se supone que el número de
albaranes crece bastante rápido y de esta forma, se supone que se optimiza
el acceso a ellos. Igualmente cada base de datos trabajará con vistas
particionadas ya que el número de albaranes es demasiado grande.

Mi propuesta es la de hacer que todos los departamentos estén en una misma
base de datos. Con esto creo que el modelo será más puro, más escalable y
óptimo. Es cierto que las tablas particionadas de albaranes serán 50 veces
más grandes pero no creo que sea ese problema para SQL Server.

Se supone que habrá unos 180 usuarios accediendo al servidor. En mi

se achaca que el rendimiento de SQL Server bajará si todos los usuarios
acceden a una misma base de datos, e incluso, a una misma vista. Yo creo

no es así, que el rendimiento del servidor no depende de "donde" accedas.
Cabe decir que no se hacen bloqueos de tablas ni de registros ( no es
necesario ) así que, no puede darse el caso de quedar todo "colgado".

¿Cuál os parece más acertado y por qué?

Gracias a todos


Xavi

Muchas gracias por contestar, Carlos. Una voz experta en mi favor

Incomprensiblemente se va a optar por un sistema, a mi modesto punto de
vista, increíble, de ciencia ficción. Se dividirán los datos en bases de
datos diferentes por departamento y mes-año!!! Os imagináis?? Si hay 50
departamentos en un año tendremos 600 bases de datos!!! Eso se evitaría si
se hace purgado de bases de datos pero ... aún así ... es increible!

Podéis imaginar de qué manera complica la programación de la aplicación,

elaboración de las consultas, el rendimiento, etc ... El número de
conexiones será alucinante, las joins buff! no quiero ni pensar!

El argumento es muy pobre: Si pasa algo con una base de datos (¿qué puede
pasar???) pues no afecta a los demás departamentos, entonces se hace un
restore de la base de datos del mes actual y ya está.

Yo he propuesto hacer DTS programados para ir haciendo purgados, volcando

otras bases de datos y haciendo backups de ellas. He asegurado que

pasará algo con los datos ( que no se corrompen! ). Pero no he tenido
suficientes argumentos ...

Con este diseño lamentable, empiezan las tablas a hacerse planas,

la integridad referencial ... pero eso da lo mismo. En caso de problemas

quiere tener un plan rápido y eficaz y, a su juicio, el modelo que

no lo da.

Qué más argumentos puedo dar?? Por favor, vosotros que sois super

cómo puedo llegar a convencer que este modelo es una auténtica basura?

puedo tener un plan de contingencia rápido en caso de "desaguisado"? Son
realmente infrecuentes estos desaguisados?

Gracias a todos!

Xavi