1

Currently we have the following US-centric database design for storing addresses:

street_address_1 text
street_address_2 text
city text
state_province text
postal_code text
country text

But now I've learned that some countries do not use any state_province classification. Now that we are improving the database, is there any other way to make this database more international-friendly?

William Entriken
  • 37,208
  • 23
  • 149
  • 195
  • 1
    Is there anything in your question not covered in https://stackoverflow.com/questions/1159756/how-should-international-geographical-addresses-be-stored-in-a-relational-databa already? – Neville Kuyt Aug 09 '18 at 14:14
  • Thank you, that's it. Feel free to flag this duplicate. – William Entriken Aug 12 '18 at 05:39
  • Possible duplicate of [How should international geographical addresses be stored in a relational database?](https://stackoverflow.com/questions/1159756/how-should-international-geographical-addresses-be-stored-in-a-relational-databa) – Neville Kuyt Aug 20 '18 at 08:52

1 Answers1

1

Nope, sadly you probably won't get this to 100% ever. Depends what you use it for? I'd consider why you are splitting out the separate segments in the first place and just KISS and have an [Address] column if it suits your use case. Have a read of this for all the problems about structuring addresses:

https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

And an interesting project trying to eliminate the problem although sadly not usable for most things yet;

https://what3words.com/

Milney
  • 6,253
  • 2
  • 19
  • 33