RE: Normalization was Left AS/400 and Returned

> From: Alan Campin
> 
> I disagree strongly about not normalizing databases because of
performance
> issues or using index files.

I disagree with your position, and I'll actually prove my point.  I'm
going to shoot down two of your comments and then get out of this
conversation, which is closer to a Usenet flame war than a professional
mailing list discussion.


> A normalized database is always simpler to code to than an
> indexed or SQL. Always.

Absolutely untrue.  And I bet your database isn't normalized either.
When you store address information, do you store the state code?  You
shouldn't, because it can be gotten from the zip code.  The state
information is redundant and thus non-normalized.

The point is that normalization can be carried too far.


> And, by the way, every time that I have seen a multi-format logical,
it
> means one thing. Bad database design.

Again absolutely untrue.  Like any other programming technique, a
multi-logical format is a tool, and when it's the right tool, it's the
best tool for the job.  A perfect example of a good use of aq
multiple-format logical is a requirements file in an MRP generation.
Because the requirements come from vastly different files (customer
order, shop order allocations, material requirements), the underlying
physicals have vastly different structures.  However, they need to be
read in a common sequence (usually by item, site and date, or some
variation therein).  The best solution is a multi-format logical.

        
In any case, as far as I can tell your generalizations seem to be
somewhat lacking when it comes down to realities of business application
programming.

Joe