How to deal with legacy records

[bluearrow]

Hi,

In a solution I am building, thousands of records are created in many of the tables during a year course. For instance, students courses and grades, lines of a project, of a quote, of an invoice, quotes and invoices itself.

There is no clear point where this records become obsolete, but it would be safe to say that, six months after the end of the year (june next year), the records are not modified, althought they are ocassionally searched for and browsed.

It would be great for searches if this records are not included in the table they search. Of course I could filter by year, but this is not the only issue here. Table size and network bandwidth is important. The file where the tables are located is around 500 Mb in size and growing (compacted and optimized). The solution contains only this one file, with many tables.

How to you deal with this?

Would reducing the number of records in a table increase performance or it will have no effect at all?

Do you have any better ideas?

Is there any standard best practice regarding this issue?

I would not like to complicate the solution too much including extra files for legacy records and associated scripts.

Thanks in advance

[Søren Dyhr]

I would not like to complicate the solution too much including extra files for legacy records and associated scripts.

Neither would I, it's a major fault in development to duplicate entities ... but I'm not saying your tables wouldn't benefit from being structured more properly, there could be the display of summary fields elsewhere than in sub-summary reports ... but searches only get rotten if it's unstored fields you're searching on.

There could be, when thing really get big, be a need not to have index'ation on all fields but instead make the search on a stored calc'field exhibiting the cartesian product of the fields in question. But this is only with very large sets of data it could be required.

--sd