> 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 

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

Reply via email to