Is there common street addresses database design for all addresses of the world?

Question

I am a programmer and to be honest don't know street address structures of the world, just how in my country is structured :) so which is the best and common database design for storing street addresses? It should be so simple to use, fast to query and dynamic to store all street addresses of the world which is identifying just by one id
Thanks a lot

Answer 1

Have a look at Database Answers. Specifically, this covers many cases:

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Answer 2

No, absolutely not. If you compare the way US and Japanese addresses work, you'll see that it's not possible.

UPDATE:

On second thought, anything can be done, but there's a trade-off.

One approach is to model the problem with address and address_attribute tables, with a 1:m relationship between them, anything can be modeled. The address_attribute table would have a pk, a name, a value, and an fk that points back to its address parent's pk. It's almost like using a Map with name, value pairs.

The trade-off is having to do a JOIN every time you want an address. You also have to interrogate the names of the address_attributes to figure out what you're dealing with each time.

Another approach would be to do more comprehensive research on how addresses are modeled around the world. In an object-oriented world you might have the western Address class (street1/street2/city/state/zip) and others for Japan, China, as many as needed to tile the address space. Then you'd have a master Address table and child tables to the other types with a 1:1 relationship between them.

How does Amazon or eBay do it? They ship internationally. Do they have locale-specific UI features? I've only used the US locale.

Answer 3

Depends on how free-form you are prepared to go with the fields. One free-form address field will obviously always do, but be of relatively little help narrowing down geography.

The problem you'll have is that there is too much variation in the level of geographical hierarchy across countries. Heck, some countries do not even have 'street addresses' everywhere.

I recommend you don't try to make it too clever.

Answer 4

Differently of other answers here, I believe it's possible to have an structured address database.

Just out of the hat, I can think of the following structure:

• Country
• Region (State / Province)
• Locality (City / Municipality)
• Sub-Locality (County / other sub-division of a locality)
• Street

But how to query it fast enough?

One way I always think it can be accomplished is to ask for the ZIP Code (or Postal Code) which varies from country to country, but is solid within the country.

This way you can structure your data around the information provided by the postal offices around the world.

Answer 5

Len Silverston of Universal Data Model fame recommends a separate hierarchy of GEOGRAPHIC BOUNDARIES and depending on how much free-formed-ness you're willing to accept either simple STREET ADDRESS LINEs or per-country derivatives.

Answer 6

Ask yourself what is the main purpose of storing this data? Do you intend to actually send mail to the person at the address? Track demographics, populations? Be able to ask callers for their correct address as part of some basic authentication/verification? All of the above? None of the above?

Depending on your actual need, you will determine either a) it doesn't really matter, and you can go for a free-text approach, or b) structured/specific fields for all countries, or c) country specific architecture.

Answer 7

For international addresses, it is remarkably hard to find a way to format the information if it is broken down into fields. As a for instance, an Italian address uses:

<street address>
<zip> <town> <region>
<country>

Such as

Via Eroi della Repubblica
89861 Tropea VV
Italy

That is rather different from the order for US addresses - on the second line.

See also the SO questions:

• How many address fields would you use for a UK database?
• Do you break up addresses into street / city / state / zip?
• How do you deal with duplicate street suffixes?
• Best practices for storing postal addresses in a database (RDBMS)?

Also check out tag 'postal-code'.

---

Edit: Reverse order of region and town - per UPU

Answer 8

It is possible to represent addresses from lots of different countries in a standard set of fields. The basic idea of a named access route (thoroughfare) which the named or numbered buildings are located on is fairly standard, except in China sometimes. Other near universal concepts include: naming the settlement (city/town/village), which can be generically referred to as a locality; naming the region and assigning an alphanumeric postcode. Note that postcodes, also known as zip codes, are purely numeric only in some counties. You will need lots of fields if you really want to be generic.

The UPU Universal Postal Union provides address data for lots of countries in a standard format. See http://www.upu.int/post_code/en/universal_postcode_database.shtml. Note that the UPU format holds all addresses (down to the available field precision) for a whole country, it is therefore relational. If storing customer addresses a flat format, where only a small fraction of all possible addresses will be stored, its better to use a single table containing all fields and one address per row.

A reasonable format for storing addresses would be as follows:

• Address Lines 1-4
• Locality
• Region
• Postcode (or zipcode)
• Country

Address lines 1-4 can hold components such as:

• Building
• Sub-Building
• Premise number (house number)
• Premise Range
• Thoroughfare
• Sub-Thoroughfare
• Double-Dependent Locality
• Sub-Locality

Frequently only 3 address lines are used, but this is often insufficient. It is of course possibly to require more lines to represent all addresses in the official format, but commas can always be used as line separators, meaning the information can still be captured.

Usually analysis of the data would be performed by locality, region, postcode and country and these elements are fairly easy for users to understand when entering data. This is why these elements should be stored as separate fields. However, don't force users to supply postcode or region, they may not be used locally.

Locality can be unclear, particularly the distinction between map locality and postal-locality. The postal locality is the one deemed by a postal authority which may sometimes be a nearby large town. However, the postcode will usually resolve any problems or discrepancies there, to allow correct delivery even if the official post-locality is not used.

Answer 9

Your design should strongly depend from your purpose. Some people have posted how to structure data. So if you simply want to send s-mail to someone, it will do. Things begin to complicate if you want to use this data for navigation. Car navigation will require additional structures to contain traffic info (eg one-way roads), while foot navigation will require a lot of additional data. Here is small example: in my city, my neighborhood is near the park. Next to the park is former airfield (in fact, one of the oldest in Europe) turned into aviation museum. Next to aviation museum is a business park. Street number for museum is 39, while business park numbers start with 39A. So it may seem that 39 and 39A are close – but it takes about a mile to walk from one to another (and even longer if going by car) .
This is just a small example taken from my city, I think you can probably find a lot of exceptions (especially in rural or wilder parts of every country).

Answer 10

Sometimes the closest you can get to a street address is the city.

I once had a project to put all the Secondary Schools in India in Google Maps. I wrote a spiffy program using the Google API and thought it would be quite easy.

Then I got the data from the client. Some school addresses were things like "Across from the market, next to the barber" or "Near old bus stand".

It made my task much harder since, unfortunately, the Google API does not support that format.