Jim writes in about his personal experience with addresses around the world. His story is a great example, representing the unique nature of finding an address. Jim Writes:
Ben … I have had to deal with this. It can be difficult for people who are centered in Western countries, or worse, in the US. I can provide a personal example. I was visiting South Korea years ago. I asked a taxi driver to take me to the address a local resident provided me earlier. Even after being in the general vicinity it took a long time to find the address.
The taxi driver had to get assistance from the local police station … The driver finally found it. I mention this just to illustrate that in other cultures and countries, there might not be an exact address. The notion of an address being the “third door after the second trash can in the alley” isn’t too far off mark.
So if you are designing forms or a database table, understand that the typical three or four input lines for street address, city, state/province, zip/postal code might have to be more involved. Furthermore, the address might be today a web address or email address. How should you handle it?
My suggestion is to keep it in third normal form. That is, break the address out into a separate logical child table. This will give you the flexibility to add as many lines as is necessary to complete a proper address. But this has to get buy-in from the business. If you have eight lines for an address, the parcel might not have room to automatically print a label. Hope this helps.
Based on Jim’s recommendation your address storage for the de-normalized presentation is not a fixed set of lines. Instead it has one or more lines, similar to the diagram shown.
That way, you store only as many lines for an address as needed. If you need 20 lines, off you go. My address in Africa would have two records, since it is two lines. In Wisconsin, USA, I have three lines. Use what you need.
Thanks Jim for the story and the insight.
Cheers,
Ben