>
> I would strongly argue that option 2 goes against the basic idea of a
> relational database, and because of that will probably generate a lot of
> trouble along the way.
>

yes i agree, but sometime denormalizing the database is the only
solution ...

>
> I have a database that's about 56 Gbyte and has 150 million or more
> records (each) in two of the tables.
>
> I find query performance to be very agreable, provided an index can be
>

yes, but when you need order by, even with index it's not funny at all :(
did we need to use the index on the query filter or on the order by filter ?
this off course depend how many record the query filter will return ...
with few reccord returned better to use the index on the query filter,
with lot of
reccord returned better to use the index on the order by ... but this
the optimization
engine can not know by advance ....

>
> So, provided all your queries will be able to use the index on
> Contact_ID, I think you will be fine. And if not, then there are
> probably better ways to handle the situation than your option 2, e.g.
> moving records to an archive table or "throwing hardware at it".
>

I already split the big table in 56 "archived like" table to reduce
the size. for now the perf are ok, but what in one year with the growing
of data :( i know that this system will soon meet the limit of firebird
OR the server himself


[Non-text portions of this message have been removed]