Re: Performance problem

SAM wrote:
>
> Brad Odland wrote in article <3435E27F.F309EDCE_at_cpm.com>...
>
> >One it sounds like you really have a datamodel problem...
>
> Not necessarily. We have 43-million rows table with
> avg_row_len=240 and it's blazingly fast.
> (A little hint: it's not really a table but a partition view
> over 44 tables).
>

Couple of comments.

Apples and oranges here re datamodel problem, speed etc. They sometimes correlate but by no means can a datamodel problem be assumed from a performance problem, conversely a fast system doesn't mean you have a good datamodel. "Good" is obviously a matter of opinion and the definition
you choose to use.  

> >WHy would you want
> >to join a table twice with such a large table....?? I would assume you
> >have..
>
> small lookup tables are very useful. You don't want to store, say,
> "Degeneral Motors", "Moobma Industries", etc similar strings in a table
> with 43 million rows. Better have a small ( ~ 1000 rows )
> lookup table with these strings and join it with big table
> when needed.
>

My opinion is that codes are old fashioned and arose from a time when space was at a premium. Store the actual values. Disk is cheap and codes just hide information. Use the 1000 row table as a verification
table. Obviously, there will be exceptions when codes are needed i.e. legacy
systems etc.
My 2 cents worth.
TRG Received on Sat Oct 04 1997 - 00:00:00 CDT