Interessant wird der Umgang mit großen (Anzahl der Datensätze und nicht notwendigerweise in GB) Firebird-Tabellen dann, wenn man einen Index rebuilden möchte, der sich physisch gesehen, nur auf einen Teilbereich der zu indizierenden Daten bezieht, wenn man eine größere Anzahl an "älteren" Datensätzen aus der Tabelle "rauspurgen" möchte da hier dann die Garbage Collection zuschlägt etc.
Das sind Dinge die man vielleicht mit ultraflotter I/O und Firebird-seitigem
RAM Tuning kaschieren kann, aber hier ist die Oracle Partitionierung echt hilfreich, da Indizes auf Partitionen kleiner und somit besser handhabbar sind. Rauspurgen ist ein einfaches DROP oder TRUNCATE auf einer Partition. Von einem unterschiedlichen Backupkonzept für ältere vs. neuere Daten in einer Tabelle spreche ich noch gar nicht.
D.h. so Easy-Cheasy kann sich der Betrieb vielleicht dann nicht darstellen. D.h. sollte man in Richtung Firebird gehen, wäre ev. eine Überlegung in Richtung Aging-Konzept mit der Pre-Aggregierung für analytische Abfrageanforderungen notwendig. In Sachen Eigenwerbung ala Holger, könnte dir mein Artikel hier eine Idee geben:
http://www.ibphoenix.com/resources/d.../general/doc_1 (Poor-Mans Materialized Views)
