Re: Re: Re: couple of general questions

"Anthony E . Greene" wrote:
> On Fri, 19 Jan 2001 17:02:43 Gregory Wood wrote:
> >> Does anyone else get annoyed when going on to an american site to
> >> register or buy something and find that the state field is only
> >> 2 characters long?
> [snip]
> >Does anyone else get annoyed when people jump all over someone because they
> >didn't spend 20 minutes proofreading something for political correctness
> >when they were trying to help someone else?
> No, but I get annoyed when I can't enter my address in a form because the
> form's creator did not consider all possible valid responses -- even for
> American addresses.....
> Some things really are a fixed length of 2 (the number of digits
> needed to specify hour of day, day of month, or month of year).
> As for the state code, it wasn't political correctness, it was a valid
> point.

I'm currently doing a website for 5 continents, 18 languages... all
from *one* set of PHP/PgSQL code. I have this to say about
states/regions/etc:

Yes, it sucks when UI fails to consider localized versions. I would
treat them the say way I would treat anybody else who didn't want
to make extra effort to get my business... I'd find somebody who
_did_ want it. For this reason, I have both a two letter state/code
entry, a county/area/region entry, and, depending on the site/area/language
used, it will validate and work with different fields.

It's usually a matter of design. Many folks in the US simply *can't*
imagine a multinational world. So let them live in their little bubble,
and buy from somebody else. Heck, have you ever noticed how many sites
only support one form of currency, or list all dates in US style, or
still use (gasp) the english measurement system (when even the english
have given up on most of it)?

Yes, it's annoying when somebody makes a crusade of it, and makes the
lives of others miserable.

But the good db-design issue is this: Target your designs for growth
outside of your current market, and you will spend less time
redesigning and rewriting. Make your zip/postal/delivery code column
at least 18 chars, and alphanumeric (many countries use letters in their
postal systems) in some way. Allow "state" to be blank (what
is somebody living in luxembourg going to put in?) Phone number fields
should support 22 chars (to allow for double growth in this space),
and so on.

It used to be that "good, tight, db design" saved as much as 20 or 50
whole megabytes, which was worth $5000-10,000 dollars (USD) per field.
Now, that same design decision may save about $10 dollars (USD), and
cost you 4-40 hours in redesign, drop, and reload, when you need to grow...
which is *much* more expensive than adding another cheap 40 GB disk.

Disk is cheap. Redesign is not. Make your fields large, and plentiful.
If you need to trim then down for fast reporting and searches, again,
disk is cheap, redesign is not, so make another (tighter) table
with triggered entries for your searching/sorting.

-Ronabop

--
Personal:  ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/
Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.