estructura de aplicación/base de datos

[Galahad]

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....