Re: How number of columns affects performance

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