Which parts of an address should be required?

Question

Say I am storing addresses in a DB table, in this fairly common break down:

address_street_line_1,
address_street_line_2,
address_city,
address_state,
address_zip,
address_country_id

(Note: I have read the questions on splitting down further, street type, house number, etc. and for this application I think it would unnecessarily complicate things.)

To work best with international users, which of these fields should NOT be required?

I'm thinking this:

address_street_line_1 REQUIRED
address_city REQUIRED
address_country_id REQUIRED

Should I require state or zip?

Thanks! Xavier

Answer 1

I would say everything except street_line_2 and state- and think of 'zip' as more of a postal codes instead of zip code - as you can tell from the variety of format based on the country of origin, this should have a pretty open format.

Answer 2

If you are not going to do any specific lookup, like searching by postal code or by city, I'd say to all combine the address in a single field. This way you will support the different address from different countries.

You will also support address oddities.

If you fear that the requirements are going to change, you could store the address as a Xml field. Modern database like Sql Server 2005 and 2008 can have an index on a Xml node inside a Xml column as long as you are using a schema.

It all come down to requirements. If the client need to group the data inside a grid by country, then you need a country column.

Answer 3

There are no states in New Zealand, so it should definately be optional. So I think you have the right answer in your question.

Answer 4

Not all countries even use postal codes, for example they were rarely used in New Zealand prior to 2006 or so. I think Ireland doesn't use them at all.

If you're truly international, city-states such as Singapore don't actually need a City field.

In the user interface, you can (and perhaps should) make the postcode required for countries where you already know it's required, since that isn't likely to change. And, if you make the UI dynamic enough, you can call it "Zip code" if the selected country is the United States, "Postal code" for Canada, "Postcode" for the UK, etc.

Answer 5

How about making none required? If the user wants to be contacted they'll enter enough information. Or, enter a single text field and let them enter free form information. They know better than you what fields are required for postal deliveries to make it to their door.

Answer 6

Even in the U.S., most of the address is not required. A large fraction of U.S. zip codes are allocated to various businesses and organizations - any mail to one of those zips will be delivered the same regardless of the rest of the address. For instance:

General Electric
Schenectady, NY 12345

Internal Revenue Service
Ogden, UT 84201-0027

The city and state are nice, but the mail will probably get delivered without.

Answer 7

The best way that I have found to solve this problem is by abstracting the logic in your application layer, and not the persistence layer. One of the cleanest/simplest ways I've seen this done is by passing the user's data in a value object (creating a common interface that's easy to validate against) to a validator with the current country code, which makes sure all the required attributes are set properly in the value object for that locale. Assuming it passes validation, pass the value object along to the persistence side of your application for storage.

The key here is the value object - you're creating a common interface that multiple pieces of your application can talk to, validate, and read/write from. You can then also use that same value object when displaying the address: have your persistence layer get the information, put it in the value object, pass it to a factory with the current locale which returns the desired address format, and send that output to the front end.

Answer 8

Making fields required is always a tradeoff. If the person doesn't want to fill in the info then they won't -- they'll put in a period, or garbage to get past the "required field" nanny.

I only require street_address_1 in my apps. Also, for the US and many countries, you can buy the mapping between the postal/zip code and the canonical city/state. It's not expensive. (The mapping between individual street addresses and zip is much more expensive.) For the US, see http://www.usps.com/ncsc/addressinfo/citystate.htm

If you're including an Ajax web interface, ask for the country first, then the post code. If in the US, then use Ajax to fetch and fill in the city/state for the user from the zip.

Some non-US countries, eg UK, can have 3 lines of street addresses if you're asking people to fill in their "preferred address" Eg:

Mirassou          (You can register a building's name with the post office
High Street        as an alternative to its street number)
Old Town
City, Bucks postal_code

Larry

Answer 9

Actually, city isn't even required in the US.

Many people have rural addresses on state and county roads. Publication 28 at the postal service web site has details. Different companies end up using the "city" field to store other information. This also applies to military base addresses.

Publication 28 link