Josh Berkus kirjutas N, 09.10.2003 kell 08:36:
> Chris,
> > The need to do a lot of joins would likely hurt performance somewhat,
> > as well as the way that it greatly increases the number of rows.
> > Although you could always split it into several tables, one for each
> > "value_type", and UNION them into a view...
>
> It increases the number of rows, yes, but *decreases* the storage size of data
> by eliminating thousands ... or millions ... of NULL fields.
I'm not sure I buy that.
Null fields take exactly 1 *bit* to store (or more exactly, if you have
any null fields in tuple then one 32bit int for each 32 fields is used
for NULL bitmap), whereas the same fields in "vertical" table takes 4
bytes for primary key and 1-4 bytes for category key + tuple header per
value + neccessary indexes. So if you have more than one non-null field
per tuple you will certainly lose in storage.
> How would splitting the vertical values into dozens of seperate tables help things?
If you put each category in a separate table you save 1-4 bytes for
category per value, but still store primary key and tuple header *per
value*.
Jou may stii get better performance for single-column comparisons as
fewer pages must be touched.
> Personally, I'd rather have a table with 3 columns and 8 million rows than a
> table with 642 columns and 100,000 rows. Much easier to deal with.
Same here ;)
------------------
Hannu
