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
