Re: Info on large tables wanted

That could work. But I wonder how easy it would be to handle new requirements from your users. Success in your tasks always invites more work. ;o) Say for instance that instead of half-hour windows, you're asked for daily ones. It would be such a pain referencing several small tables. Even moving them around into a single table is quite expensive.

So before you commit to a particular approach, I strongly encourage you to read that document and other related literature. Always look for a better way; most of the time there is one. For example, your idea above, partitioning might be better. You get a unified view of the data (as a single table) while at the same time, partition pruning ensures that Oracle only reads the relevant partitions (kinda like sub-tables). And if you're dealing with summary figures, you might wanna consider materialized views. I could go on and on because there's just too many possibilities. But just read the doc.

Good luck!

Romeo

"Markus Vohburger" <markus.vohburger_at_t-online.de> wrote in message news:<ca10p5$hii$03$1_at_news.t-online.com>...
> Thank you for this link!
>
> I have not yet decided on what Hardware it is going to be run, i will
> collect further information first. I think that i can compact the data on a
> half-hourly basis, as they only need to know how many pretzels they sell
> between 10:00 and 10:30 for example, this gives quite small tables. But it
> would be quite interesting for them to have a complete sales Journal for
> future expansions. I think i will store the raw data in a seperate
> tablespace and generate compacted data from the raw data as well to be
> stored in a much smaller table for the actual reporting.
>
> MV
>
Received on Mon Jun 07 2004 - 09:06:04 CDT