Re: Normalization was Left AS/400 and Returned

["Brad Stone" <brad@xxxxxxxxxxxx>]

I believe zip and county are the main factors.  At least I
seem to remember that from working with Vertex (the death
project at my old shop.. lol.. you got put on that, you'd
leave the company in a few months).

That may be just for taxes, though.

Bad

On Wed, 4 May 2005 12:40:59 -0500 (Central Standard Time)
 "Booth Martin" <booth@xxxxxxxxxxxx> wrote:
> 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.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com