Re: db design for measurement data?

Datawarehouses are rarely updated in real time. The lag gives you time to do bulk loads of data, to clean the data if necessary. to calculate any desired summaries, and to rebuild the indexes. Rebuilding the indexes on the fact table would be a burden with a new row every second all day long. I don't know what the queries will look like, although since you can't use any summary information I'd guess they're pretty specialized. As the amount of data grows ever larger, you'll need some way to partition it or the queries will run ever slower.

Van

"Ronald Schirmer" <roschi_at_hrz.tu-chemnitz.de> wrote in message news:3B091420.21E82C87_at_hrz.tu-chemnitz.de...
> Hi Van,
>
> thanks for your reply.
>
> > It depends on what you want to do with the data. Do you need every row
> > available or will summaries suffice?
>
> I will need every row. There will be no chance to shorten or summarize
> the measurement results.
>
> > Does the data have to be available immediately or is some lag permitted?
>
> Depends on what you consider "some lag" :-) . When a query (e.g. via web
> frontend) is made to the data base, the results should be retrieved
> within a few minutes.
>
> > Can you use a datawarehouselike star schema?
>
> I've already heared about "datawarehouselike" things - but I've got no
> clue what that is? Could you, please, explain or do you no a useful URL
> dealing with that topic?
>
> > How long do you have to keep the data available online?
>
> This is going to be a long term project, so there's no
> end-of-store-date.
>
> > Can you partition your tables (in Oracle)?
>
> I'm not sure yet, which dbms to use. I wanted to decide after the db
> design.
>
> Thanks for every hint.
>
> Ronald.
Received on Sun Jul 22 2001 - 01:25:13 CEST