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