Re: Many fields in one table or many tables?

Alexander,

> I am in the process of creating a database design in which LOTS of data
> need to be modelled.
>
> For instance, I need to store data about products. Every product has LOTS
> of properties, well over a hundred.
<snip>
> Do any of you know if and how PostgreSQL would prefer one approach over the
> other?

Queston 1:  Do all products have all of these properties, or do some/many/most
not have some properties?   If the answer is the former, then a single table,
however broad, is the logical construct.  If the latter, than several tables
makes more sense: why create NULL columns for stuff you could just leave out?

Question 2: Is it true that some properties will be updated *much* (100x) more
frequently than others?   If so, it would make sense from a
performance/postgresql standpoint to isolate those properties to related
table(s).  Keep in mind that this recommendation is strictly performance
related, and is not necessarily the best relational design.

Suggestion 3: There was an issue in 7.3 with table rows which are overly broad
-- some problems with PSQL, I believe.   It would be worth searching for, as
I cannot remember what the limit is where problems occurred.

--
Josh Berkus
Aglio Database Solutions
San Francisco