Re: Oracle performance - Table with 480 fields

I make 5-minute reading over 24 hours 288 readings.

The most important questions to consider are how the values get into the database and how they are queried.

If you want to read

    'all the readings for curve X on day Y' then you get optimum query performance by having all data the in one row.

If you want to query for:

    the 9:30 reading for all curves
then you benefit from having one row per reading per curve.

Is each set of 24 hours really totally independent of every other set ? Will you need to collect more than one set of data to map a curve over 2 days.

Do all the time-points on the curve match exactly, or do you have to have a 'start-time' record for each curve.

Are you loading data 24 hours in arrears so that all the values for a curve arrive at the same time, or do you get all the '9:35' points, then all the '9:40' points etc.

How important is data loading speed compared to data retrieval speed ?

There are plenty of options, but no point in suggesting them without any idea of how you plan to use the data.

--

Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk

Melissa Star wrote in message <388CEDD3.7837D7F2_at_inspiration.com.au>...
>Hi everyone,
>
>Do you know if a table with 480 fields will perform well, and whether it
>
>will cause a significant performance difference compared to an ordinary
>table with 20-30 fields?
>
>The table in questions needs to store time-related curve data,
>basically, five minute readings over a 24 hour interval.
>
>If the performance is not going to be acceptable with 480 columns, what
>would be the best solution to store the curve data?
>
>* A one to many relationship or design in which an entire 24 hours is
>not contained in one row may be impossibly slow, since the table will be
>
>accessed VERY frequently
>
>* Using Oracle 8i's array type?
>
>* Storing the full 24 hours of data at a BLOB and manipulating it
>oustide of Oracle only?
>
>Thanks everyone,
>
>Melissa Star
>
Received on Tue Jan 25 2000 - 13:41:59 CST