estructura de aplicación/base de datos
 

hola, buenos días...
Estoy pasando mi aplicación de tablas paradox a firebird, la estructura de mi aplicación con las tablas paradox era la siguiente:
Carpetas individuales para cada empresa, por ejemplo 001,500,400,etc,
al final de año, se creaban otras carpetas para guardar los datos del año anterior por ejemplo en el 2007, se crean las empresas/carpetas (donde se vuelca la información) 007,507,etc....
la tabla más grande tiene unos 200.000 registros y cada carpeta puede tener un peso de unos 600 Mb.
Una vez informado de los límites de firebird/interbase (parece ser que soporta varios Tb), estudié que el tamaño de la base de datos final iba a ser de unos 5-7 Gb,mi idea era volcar todas las empresa y todos los años a la base de datos, estructurando las tablas incluyendo los campos Empresa+Año.
El tema es que buscando por este foro, encontré un hilo similar a este en el que se recomendaba crear una base de datos por cada empresa/ano. Realmente pienso que con el esqueme que estoy desarrollando,'penalizo' la estructura de la base de datos por incluir en la misma información de años que es raro que se necesite consultar. Además, estaria incluyendo en la misma base de datos, información de varias empresas que no tienen que compartir información.
Por otro lado, parece ser que firebird puede trabajar con un volumen de datos como el que comento sin problemas , teniendo en cuenta que el hecho de que en una sola base de datos se centralice toda la información aporta otras ventajas indudables.
¿ Que opción sería la más óptima ?

1.-) Una única base de datos (cada 5 años-5Gb pasar a una base de datos histórica.
2.- Una base de datos por empresa+año (tendria unas 15-20 bases de datos diferentes).
3.-) Una base de datos por empresa (tendria 3-5 bases de datos,unas con pocos datos y alguna con 10 veces más).
4.-) Una solución intermedia, tener 2 años (la información que normalmente es más necesario consultar) de todas las empresas, y a partir de ahí , el resto pasarlas a históricos.

¿ que solución es la más recomendable teniendo en cuenta el equilibrio rendimiento base de datos-centralización de la información ?

P.d. - Perdón por la extensión del tema.... :D

Yo haría una única base de datos, asi vas viendo si tus consultas e indices van bien con un volumen grande de datos, si ves que que tus consultas se relentizan antes de los 5 años que propones crearía un histórico en ese momento o mejoraría la consulta/indices.

Saludos, Tony

Por mi parte coincido con lo que te han dicho. Creo que el diseño correcto sería una Base de Datos con todos los datos. Si FB no "llega" por el volumen de la Base de Datos, pues estudia cxambiar a otro mo0tor más potente, pero no creo que sea buena idea cambiar a un mal diseño por esa razón.

El tema del histórico es independiente y recomendable. Cada x tiempo puedes hacer ese proceso independientemenete del diseño final que escojas.

Hola,
yo haria una base de datos por empresa, creando su propio backup al llegar a ciertos limites, ya sean de años o de tamaño

Base Datos
 

Si puedes soportar todo, con una base de datos, puedes gestionar información entre empresas, Impagos por empresa, facturación por empresa, Clientes de todas las empresas, Empreados de todas las empresas.
Solo tienes que gestionar un Backup, para todos, puedes gestionar varios backups diarios, incluso un servidor con replicación por Harware, cada noche una cinta puede guardar todos los backups del dia.
Los clientes que la linea telefonica, de poco canal, puedes ponerles clientes Citrix, es como si trabajasen en el servidor, los que tienen canal amplio, puedes hacer conexión directa.

La verdad, creo que con una base de datos, para todos, las mejoras administrativas son muchisimas, cuando veas, que la cosa, va lenta, puedes gestionar de nuevo indices, o incluso crear un historico, y dejar los dos ultimos años en la base de datos original.

A mi Firebird, siempre me sorprende por lo bien que funciona.

Saludos

gracias
 

ok, gracias a todos, optaré por crear una única base de datos,

saludos...