Subject Re: time series and FB/IB
Author Jan Pomahac <>
--- In, Svein Erling Tysvaer
<svein.erling.tysvaer@k...> wrote:
> At 13:23 10.12.2002 +0000, you wrote:
> > > The series table could be a good idea, but don't use the
> >as part of the PK of another table. Use a generator to populate
the PK,
> >never use composite primary keys.
> >
> >Why? I think that index on "series_id" would have low selectivity,
> Of course you can have an index with series_id, and there's nothing
> with an index (series_id, PK) - I just didn't like it being part of
the PK.
> When I learnt database programming at school in the late 80s, we
> composite keys, but when I started using Interbase in late 1998 I
was told
> that meaningless keys populated by generators was the way to go.
Why? I
> never actually asked that question, just started using such keys
(as usual,
> I haven't been 100% obedient in all cases). But I have made me some
> 1) Meaningless keys mean less trouble if the meaningful, visible
keys or
> the database structure change
> 2) Atomic keys makes it simpler to link to other tables
> 3) Atomic keys are shorter, hence I suspect databases designed that
way to
> be marginally faster with joined queries
> 4) Ann and/or Helen says it is the way to go, and they normally
know what
> they are talking about ;o)
> My reasoning is no argument to change any small system that works
OK, but
> for complex systems that isn't working as they ought to or is
tedious to
> maintain, I think one ought to stick to atomic keys rather than
composite ones.
> Set

I'll try both aproaches and will see the results.
Another question which comes to my mind is this data table structure:

pk integer,
series_id integer, (FK)
time timestamp,
value double precision

This would result in table with 350 000 000 rows and very fast
growing (45 000 000 row/year). Can FB/IB handle such tables?

Jan Pomahac