The analysts and developers amongst you will probably need to design an approach to capturing and storing postal addresses at some point during your career.
On a typical project, the design for this aspect may not be considered significant. It is, more than likely, just a handful of user stories in comparison to a burgeoning product backlog (aka requirements for any Waterfallers).
As such, how many address data structures get designed with three simple requirements in mind:
- Does it store my address?
- Does it store the address where I lived as a child?
- Does it store my work address?
Now I wouldn’t recommend basing your design decisions on your answers to these questions but it might not be a bad start. In fact, you may find that you can support most addresses in this way.
But there are some “edge” cases that can cause problems. It’s these situations that might disrupt someone entering their address on your payment form (sale lost) or prevent your marketing team from delivering their message (truncated address on envelope).
Here are six things to remember:
1. Addresses can be unreasonably long
The longest address on PAF belongs to the human resources department of the government offices on the Isle of Man.
Isle of Man Government Office of Human Resources
Learning Education and Development
The Lodge Education and Training Centre
Braddan Road, Strang, Douglas
Isle of Man
Ensure your data structure field length can support this example (and then some).
2. Addresses can be unreasonably short
Like this one for instance: Elba, DUNS, TD11 3RY.
Don’t validate fields on the basis of their length alone.
3. One postcode can cover more than one street
Not usually but sometimes: HD7 5UZ in Huddersfield covers 7 streets.
Don’t use postcode and house number as a primary key, it’s fallible.
4. One postcode can cover more than 100 residences
CV4 7AL provides over 5800 residences for the students and staff at the University of Warwick.
Consider how best to page through addresses on your user interface.
5. Addresses can include both a building name and a number
Here’s one such example:
Apartment 1 Sub-building name
The Jam Works Building name
49–51 Fleet Street Street number and street
Design to capture and store both (and don’t use a generic house name / number field).
6. Postcodes don’t always relate to a geographical area
There are several memorable postcodes in PAF® like GIR 0AA for Girobank (it’s just a pity they went and changed their name to Santander).
Don’t rely upon the first two characters always helping you to resolve down to an area.
These our own thoughts but if you want to read more, check out Falsehoods programmers believe about addresses. It’s an interesting read (even if you’re not particularly interested in addresses).
Our postcode lookup API can also help you handle all of these too.