Francisco, > Yes all fields belong to the same entity. I used 100 as an example it may > be something like 60 to 80 fields (there are two tables in question). I > don't formally do 3rd normal form, but for the most part I do most of > the general concepts of normalization. > > > If not, then good design says to split the table.
Actually, no, it doesn't. If all 60-80 fields are unitary and required characteristics of the row-entity, normalization says keep them in one table. The only time NF would recommend splitting the table is for fields which are frequenly NULL for reasons other than missing data entry. For those, you'd create a child table. Although while this is good 4NF, it's impractical in PostgreSQL, where queries with several LEFT OUTER JOINs tend to be very slow indeed. My attitude toward these normalization vs. performance issues is consistenly the same: First, verify that you have a problem. That is, build the database with everything in one table (or with child tables for Nullable fields, as above) and try to run your application. If performance is appalling, *then* take denormalization steps to improve it. I'm frequently distressed by the number of developers who make questionable design decisions "for performance reasons" without every verifying that they were, in fact, improving performance ... -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
