RE: Normalization was Left AS/400 and Returned

Not necessarily.  There can be multiple towns with the same zip code.  I'm 
a happy customer of Zip City by WorksRight.  Each month, when they send 
out an update, they tell you some interesting trivia like this.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Booth Martin" <booth@xxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/04/2005 12:40 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: Normalization was Left AS/400 and Returned






This raises a question that has bothered me for some time:  Why do we 
store
town and state anymore?  Zip code does it all, doesn't it? 

 

---------------------------------

Booth Martin

http://www.martinvt.com

---------------------------------

-------Original Message-------

 

From: Midrange Systems Technical Discussion

Date: 05/03/05 18:34:20

To: 'Midrange Systems Technical Discussion'

Subject: 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

 

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx

To subscribe, unsubscribe, or change list options,

visit: http://lists.midrange.com/mailman/listinfo/midrange-l

or email: MIDRANGE-L-request@xxxxxxxxxxxx

Before posting, please take a moment to review the archives

at http://archive.midrange.com/midrange-l.

 

 

.
-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.