Re: Modeling Address using Relational Theory

dawn wrote:

>
> I don't see the irony. What I see is that there are times when it might
> make sense to haul out some operators on the "addressLine" domain to
> parse it out, but there is little need to model these address lines
> with pieces split out. Custom routines have been and can be written
> for those few instances where this is important, compared to the
> routines that otherwise need to be written and executed frequently for
> pasting address lines together.
>
> Have you ever seen an implementation of "the correct table design" (or
> even close) for a relational model of address data as you see it?
> --dawn

I wrote a system that would generate databases on the fly that had CASS-certified address columns as described above. This was for a direct marketing outfit.

For line-of-business projects I've always done Address1, city, state, zip. I find it much better to split out city/state/zip cuz you can get databases that let you validate one to the other, or to fill in city and state from zip. Plus people may want to do lookups on city/state, so its good not to mash them into "Address3".

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)