international address and phone formats

[Jason Langston]

Hey all,
Building a member database for e-commerce site, that has potential to be
international. Normally here in the US I just do the typical street, city,
state, zip.
Any input on a good db layout to accomodate not only US, but also
international addresses?
Ditto for phone formats.
Thanks,
JasonL

[Avron Polakow]

Chack out the attached file which has potential but must be amended to cover
more cases.

Some of the data is only a sample. I'm not American so the state abbreviations
and names are guesses.

I suspect you are going to find it difficult for complete coverage of all
possibilities. Here are some:

- Many countries have different abbreviations for different parts of the
address. (St, Ln, Blvd, Av, ....)

- Some have a different order for the address parts,
eg, we put the street before the number and the apt# after the street
separated by a slash

- In England suburbs are used in the address.

Phone Numbers can be more of a headache, espec. when it comes to placing
hyphens and use of letters.

Avron

Jason Langston wrote:

> Hey all,
> Building a member database for e-commerce site, that has potential to be
> international. Normally here in the US I just do the typical street, city,
> state, zip.
> Any input on a good db layout to accomodate not only US, but also
> international addresses?
> Ditto for phone formats.
> Thanks,
> JasonL

[Brett N]

Jason

Don't use the word ZIP CODE, no one knows what it is, the US is the only
place with ZIP codes, every one else has post or postal codes. IF you must
use ZIP, use ZIP, use something like ZIP/POSTAL CODE as a lable. I could
tell you 1000 things that anoy non-US citizens when they visit US sites
(what about the classic that allows you to choose a country, but has data
validation to force you to select a 2 letter US state abbreviation ,the
number of times I've seen that one!).

A simple piece of advice, do not make assumptions on the way people do
things in other countries, don't ask for information that is available in
the US, like a social security number, that is not available in other
countries. Don't tell users that you cannot accept PO Box numbers, in many
countries there is no door to door delivery and mail must be collected from
the post office or is sent to a business address.

If you want to accept international phone formats, I'd just accept anything
and parse out all the spaces & characters before sticking the value in your
db. I have a friend in Kenya whose number is a 4 digit area code followed by
7! That's his phone number, 7! He get's real annoyed when sites tell him
that he has not entered a valid phone number, it's perfectly valid, you can
call him now! This is a good example of the problem of assumptions based on
your own experience, they tend to be wrong!

Sorry this is not a very technical answer, like 'here's the db structure
you're looking for', but I hope it helps in your approach to your design.

Brett

Jason Langston <jason@DONTSPAMMEwirelesszone.com> wrote in message
news:39b79c06@news.devx.com...
> Hey all,
> Building a member database for e-commerce site, that has potential to be
> international. Normally here in the US I just do the typical street, city,
> state, zip.
> Any input on a good db layout to accomodate not only US, but also
> international addresses?
> Ditto for phone formats.
> Thanks,
> JasonL
>
>

[James Dooley]

Use Postal Code instead of ZIP code also don't make
State a required field, as most countries do not have
such a concept.

James
http://www.siteknowhow.com

"Jason Langston" <jason@DONTSPAMMEwirelesszone.com> wrote in message
news:39b79c06@news.devx.com...
> Hey all,
> Building a member database for e-commerce site, that has potential to be
> international. Normally here in the US I just do the typical street, city,
> state, zip.
> Any input on a good db layout to accomodate not only US, but also
> international addresses?
> Ditto for phone formats.
> Thanks,
> JasonL
>
>