Gary,
It appears that your 130 columns are probably significantly
duplicated in each stock. So it is possible to keep them
in one table with an additional stock_id column. It seems
that you would have a natural primary key in (stock_id asc,
stock_data_date asc). Also, consider that if there are some
unique columns applicable to only some stocks you could still
include them in the overall columns with the stocks where
that columns is not applicable having a null value. You
could have a separate table that would serve as a datadictionary
of (stock_id, Stock_name, [other info], col1_avail, col2_avail,
... col??_avail).
Depending on how long your update/calculation/reporting process
takes it may be necessary that you partition data into separate
databases in order to do parallel processing.
I don't think the separate dbase files method is feasable
as you still face possible column limitations as you attach
and detach the dbase files. Column names for dbase files
count against the R:Base limits.
Remember the following:
each view counts against the table limit
columns defined in "CREATE VIEW view_name (col1 col2,..)
AS SELECT ...." may also count againts column limits
You must deduct approx 156 from column count for system
columns
You must deduct approx 23 from table count for system
tables
don't overestimate work in duplicating maintaing forms,
reports, procedures, command files.
--
Jim Bentley
American Celiac Society
[EMAIL PROTECTED] - email
(973) 776-3900 x5029 - voicemail/fax
---- "Michael Young" <[EMAIL PROTECTED]> wrote:
> Hi Gary,
>
> The database holds many years of price data information
> on about 700 - 800
> stocks. This involves the technical analysis of stocks.
> It will take the data
> and calculate about 120 indicator values and store them
> in the database. One
> value for every day of data. Then another routine will
> analyse the data giving
> the best indicators that worked during certain periods
> of time. These
> indicators will be stored in the database and the daily
> data will be tested by
> these optimized indicators giving buy and sell signals.
> It is actually even more
> complex but that gives you the gist of what is happening.
>
> Best regards,
> Mike Young
>
> On Wed, 26 Sep 2001 08:57:31 -0700, Gary L. Winzeler wrote:
>
> >As many have ask......
> >
> >WHY 700 tables??
> >
> >You have really sparked my curiosity.
> >
> >What are you doing??
> >
> >GARY
> >
> >
> >
> >At 09:50 AM 9/26/01 -0500, you wrote:
> >>Michael,
> >>
> >>Are they in effect the same 130 columns in all 700 tables?
> Could you
> >>possibly have one table with 131 columns, the extra one
> to identify
> >>what distinguishes one of your tables from another?
> Seems like that
> >>would reduce coding effort by a huge factor, too, since
> you wouldn't
> >>have to have code to deal with 700 table names, and forms
> and reports
> >>that dealt with 700 tables.
> >>
> >>Bill
> >>
> >>On Tue, 25 Sep 2001 23:12:51 -0700, Michael Young wrote:
> >>
> >> >Hi Ben,
> >> >
> >> >Actually I would prefer to keep them in one database
> but as you have
> >>seen in
> >> >other posts I am exceeding the number of columns so
> I am forced to
> >>either
> >> >use a DBASE file or multiple R:Base databases.
> >
> >Regards,
> >
> >Gary L. Winzeler
> >
> >DAQtech, Inc.
> >Data Acquisition Technology
> ><mailto:[EMAIL PROTECTED]>
> ><http://www.daqtech.com/>
> >
> >Office 408-847-4800
> >Fax 408-847-4097
> >Cellular 408-483-7739
> >
>
>
>
>
__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com
