GeekForce

In the years I’ve been doing this code stuff - I know this is really stupid - I’ve still yet to find a really elegant way for systems to handle addresses. You’d think that by this time, I’d have some kind of magic mdoule that I could plug in to any software system to deal with this problem.

Well, you’d be wrong! This problem is a constant nag to me, mostly because I see thesolutions implemented by others. I’ve never taken it upon myself to build something that would really work.
What does that mean?

Lets look at a few addresses:

7777 Hanley Rd.
Ste. 1450
St. Louis, MO 63105-
USA

Hurdacker Str. 30
CH 8049
Zurich, Suisse

These represent the same information. They tell a postal employee what route will deliver the package. This is mostly derived from the postal code. Postal codes represent the region of coverage for a set of postal routes. as such, they do not respect any kind of geopolitical boundary - they can cross them.

But that’s not the point here. What we want is the optimum data representation for an address. I’ve pretty much always argued that the best possible way to do this is just to give the user a text box to type the whole address into.

This causes two problems.
1) users dont know what to type - they try typing any old thing in to that box.
2) Using the address for more focussed geographic applications is not going to be easy due to the lengths that programmers must go in order to parse the information.

Giving users any kind of free form text area has always been a bad idea. Every application I’ve ever dealt with has had text boxes for notes. These always end up being used for business critical piece of information that gets lost when it gets stored in there.

Since we want to be able to query on these addresses for things that are geographic in nature, and perhaps even geopolitical, then it stands to reason that we need to break the address in to its components, and store them separately. Here you can see the problem. Each culture represents that data in a different way.

I found this site that lists different address formats. Based upon this, it looks as though we need to break the address in to many more components than is usually thought. The street number must be a separate field from the street name. This is because some addresses when printed or displayed, show the street number last, like the Swiss one above.

We also need a way to be very flexible with postal codes, we need provisions for tying a country code to the front of the postal code, in the case of countries in the EU. I would argue that moves like this should be handled automatically, based upon some kind of templating system.

The other question that I have is this: Does an address include the recipient? or does an address simply refer to the physical location of a mailbox? To not include the recipeint is to lose one piece of critical information, which I would argue belongs in a separate field. the recipient, and the address can be different things. What I mean by this is that one does not imply the other.

So lets look at the fields that we have so far:
Street number, street name, street type, suite/apt. number,floor,city,state,postal code,country

These dont have to be in any particular order in terms of our representation. It’s just the use of them that matters. The presentation to the end user doesn’t even have to conformto anything, we just need a templating system that can mask inputs - hey that’s a cool idea, eh…

Am I missing anything here? BTW all of these fields ar varchar’s in the database.

All we need now is some kind of templating system that can tune itself for each culture that it gets a request from. Voila, you can turn this data into a valid address for whatever culture is requesting it.

This seems like a really radical system change to me. Imagine if Amazon had to plug this into their systems, it could be a real nightmare that would require at least a year of work to change. If it got done though, they could be sure that package delivery would be far more efficient.