Re: seeking advise on DB tables, split or not split

Hello,

> I'm surprised that you say this. (The two choices were 1.) a single
> humungous table, vs. 2.) splitting a 50-column table into parts and paying
 a
> supposed performance hit for joins later.)
>
> First, why is there going to be a performance hit? Is every query going to
> use all fifty columns?
>
> Second, I thought the whole point of the relational revolution was to
 enable
> better maintenance -- the major cost in all of softwaredom -- by breaking
> huge kludges into manageable parts.

Not by braking an entity into serveral pieces but by minimizing redundancy using normalization.
If you have an object with 50 properties and it can not be normalized than IMHO it is best to create that table with 50 columns. I think breaking the table
into pieces will make maintenance more complex (for example deleting one record will have to remove records from several tables).

>
> Why are you recommending the bad ol' days, when we have tools now to let
> things be split into rational and sensible sub-sections, in this case
> related tables

The sugested method is not relational.

Rob. Received on Mon Apr 10 2000 - 00:00:00 CDT