Re: Modeling Address using Relational Theory
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 28 Aug 2005 22:56:11 -0400
Message-Id: <m1aau2-8nl.ln1_at_pluto.downsfam.net>
>
> Yes, I've got the "representation specs" for an address on an envelope,
> but what is the logical relational model related to such addresses?
> Again, you can skip the city, state, country, and postcode unless they
> are not modeled with attributes such as city, state, ...
>
> What is a good relational data model for the rest of the address?
> --dawn
Date: Sun, 28 Aug 2005 22:56:11 -0400
Message-Id: <m1aau2-8nl.ln1_at_pluto.downsfam.net>
dawn wrote:
> -CELKO- wrote:
>> Look at the US Postal Service specs. You use a five line label with 35 >> characters per lines. ZIP+4 is CHAR(9), the State code is CHAR(2) and >> so forth.
>
> Yes, I've got the "representation specs" for an address on an envelope,
> but what is the logical relational model related to such addresses?
> Again, you can skip the city, state, country, and postcode unless they
> are not modeled with attributes such as city, state, ...
>
> What is a good relational data model for the rest of the address?
> --dawn
Dawn, there is no 'relational version' of the information, it is what it is. Put into a fixed-field width text file there would be fields, in an XML file there would be elements or tags or whatever, and in a table they would be columns.
An address is not subdividable in any way that requires normalization, that is why there is no "normalized" or "relational" way to store an address.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Mon Aug 29 2005 - 04:56:11 CEST