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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to