I've argued many times for making address one big text field. Let people who live in the country, who own the address, format it how they know it should be formatted.
Unfortunately, one big text field doesn't cut it when every other system you interact with requires separate fields.
Bad reasons given:
- Safeguard against users who can't be relied on to format their own address properly. Fix 1: Don't worry about that. Fix 2: If you really want this, leave the rest of us an option to use a freeform address instead.
- "Out webshop database has these fields." Fix: Change the database, then.
Or let the app first sort out the raw input, make sure it makes sense, then pass it on to the database.
I can see wanting to have fine-grained table fields. But I don't like seeing the schema drive the model or the UI.
A single textarea really is a strong idea (and like others here have been advocating it fr a few years with mixed results).
Seems like these are the sort of mundane tasks computers should be good at. Let humans be quirky and let computers sort it out. Prompt for confirmation as needed.
Much harder when the "database" belongs to a third party such as UPS or Paypal.
1. If you need to integrate with third party systems who require you to break up the address. In case you've never tried, parsing addresses is very hard -- if not impossible -- depending on how many formats you need to support. All it takes is one third party library that requires you to break them up to make your life miserable.
2. If you need to categorize your users by country, state, zip, etc. For example, if you need to handle different tax laws for different states or if you need to generate reports on how many users you have from country XYZ.
Honestly this seems like a problem that could be solved once and we all would benefit... And like any good problem, there is probably a profit to be made from it.
It's a terrible system really, and the only solution that I've been able to rely upon is having the user parse their own address and supply it to me. At least that way I don't have to spend hours looking through regex statements and edge case detection logic to figure out why a street address was parsed in a particular way.
Then you stick them altogether and print them on the envelope, thus covering chapter2 = report generating.
My suggestion is to give the option to enter generic information but don't let that become the default.
* allow the user to enter a free-form address, normalize it and then prompt the user for confirmation that the normalization was correct.
* Allow the user to edit fields on the confirmation page.
* Log any differences between the normalization and what the user changes for further refinement of the normalization process.
* Don't require fields that may not be relevant to all addresses that you plan to capture.
* Allow some sort of contact avenue on the address confirmation page so that they can complain when the interface doesn't allow them to properly enter their address. (If people hit a brickwall while trying to submit their address, they are more likely to just give up if they have to hunt down contact information. At the very least, if there is an easy way for them to complain, you get some sort of feedback even if you lose them as a customer.)
Is there some huge performance advantage in having the state field be an Id into a states table? Perhaps it would make updates easier if they ever rename Washington?
Why not normalize the name? There must be lots of Johns in your DB
It makes more sense to normalize it at the beginning in order to give the user a chance to approve that it was processed correctly. You could just do the normalization at the point when you need to interact with the 3rd-party services, but then it's hidden in the back-end so you have to be confident in your normalization processing.
You could roll out a solution where the confirmation page is just there to allow the user to approve that normalization works on their free-form address, but still store it as a chuck of text in the database. Then when you are confident enough in your normalization process, you could just remove the user confirmation part.
Sure, there are other ways to normalize an address from freetext input, but they often require using a third party system from FedEx or UPS.