February 9, 2015 at 2:54 pm
HI all,
I was wondering if anyone knew about best practices when it comes to managing addresses worldwide. In the past, i've only designed dbs in the US and Canada and so did it with a simple State table (StateID, StateName, Abbr) with the stateid linking to the Customer table or where ever.
US and Canada tables are free all over the place. But for the world i don't know how to begin. I've looked around for 'worldwide state table' examples and can't find much. Basically i need a way to keep my address data clean and verified, so don't want to just use a varchar field.
Does anyone know where i could find a global state table? or perhaps some other way to solve the problem?
Thanks so much guys,
Drew
February 9, 2015 at 3:29 pm
You might have some issues with that as not all countries use the same format address.
February 9, 2015 at 4:57 pm
Many countries don't call them states, they call them provinces.
Having said that, if you find one I too would be interested. But aside from scraping them off the wiki page for each country, I'm afraid you'll probably have a hard time digging them up.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
February 9, 2015 at 5:15 pm
This is interesting, but I have no idea how complete/current it is:
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
February 9, 2015 at 5:36 pm
dwain.c (2/9/2015)
Many countries don't call them states, they call them provinces.
And France is divided in regions, departments, arrondisements, cantons, communes and, in some cases, municipal arrondissements.
I'm sure that other countries will have different problems.
February 9, 2015 at 6:01 pm
Luis Cazares (2/9/2015)
dwain.c (2/9/2015)
Many countries don't call them states, they call them provinces.And France is divided in regions, departments, arrondisements, cantons, communes and, in some cases, municipal arrondissements.
I'm sure that other countries will have different problems.
Of course! Thailand: changwat, amphur, (forget the next level), mooban!
Changwat=province.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply