Re: trying to determine best DB schema design
> unique table for each...
That is almost always a bad design.
> millions of tables
Really bad. I have seen Operating Systems moan and groan with 100K tables. (A table is 1-3 files. If the tables are in the same database, then those files are in the same directory.
> if the table sizes are small
Does not help.
What will you do with the 'timeseries'? Simply regurgitate upon command? Then it may as well be a long string (perhaps MEDIUMTEXT CHARACTER SET ascii) as a column in some table. If you need to select on items in the timeseries, or need to do math (in SQL) on it (such as AVG()), then it is messier.
The timeseries table might have
ID, Userid, date, series, metadata-about-the-series
> and the ID field is written to the time series data
I don't understand what the ID is for.
> 1 - Stat1
It might help if I had a clue of what "Stat1" is like. Is it like stdev?
Then consider...
ID (for this table), seriesID (for joining with the timeseries), name (eg, 'stdev'), value (DOUBLE).
INDEX(seriesID) would let you go from the series to all the SomeStats.
Subject
Written By
Posted
Re: trying to determine best DB schema design
June 02, 2013 01:28PM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.