Address DB schema - more ForeignKeys or just plain text? - django

Question

I have a dilemma designing a database for my application. Basically, I want store US addresses. I'm using Django, but it's more of a database design question.
Say, I have models for State, City & ZipCode:
class State(models.Model):
short_name = models.CharField(_('state short name'), max_length=2, primary_key=True)
name = models.CharField(_('state full name'), max_length=50)
class City(models.Model):
name = models.CharField(_('city name'), max_length=100)
state = models.ForeignKey(State)
class ZipCode(models.Model):
code = models.CharField(_('zip code'), max_length=6)
city = models.ForeignKey(City)
Then, I want to store a single Address. Here is my dilemma: should I use Foreign Keys (or just a single one) or store the whole address as a CharFields? That is, should I use 1st, 2nd or 3rd version of Address model:
1st version:
class Address(models.Model):
street = models.CharField(_('street address'), max_length=300)
city = models.ForeignKey(City)
zip_code = models.ForeignKey(ZipCode)
state = models.ForeignKey(State)
counter = models.IntegerField()
2nd version:
class Address(models.Model):
street = models.CharField(_('street address'), max_length=300)
city = models.CharField(_('city'), max_length=300)
zip_code = models.CharField(_('zip code'), max_length=6)
state = models.CharField(_('state'), max_length=50)
counter = models.IntegerField()
3rd version:
class Address(models.Model):
street = models.CharField(_('street address'), max_length=300)
zip_code = models.ForeignKey(ZipCode)
counter = models.IntegerField()
My specific use case is that every user search will either generate new Address (if one doesn't exist) with counter = 0 or update existing Address (say, increment counter field; this is just an example). Assume 1 search per second with ~30% of redundant searches.
My notes of different versions:
1st:
overhead with creating new record (worst case: need to create new City & Zip; States will be already populated)
more connected data (not sure if that's a pro/con?)
2nd:
fast creation of new Address record
less "connected" data (not sure if that's a pro/con?)
3rd:
Zip_Code is already assigned to a City, which is already assigned to a State, no need to copy this data
I'm just not sure which schema is better and why. For now I've been using "plain" data, that is no Foreign Keys on the Address, just CharFields and it works ok. But my site is growing and I want to have a solid foundation. Also, I'm really curious how to approach such problem.
Thank you for taking the time to read this.

Answer 1

Thinking about it conceptually, does this hold true?
A state has one or more cities.
A city has one or more zip codes.
A zip code has one or more street addresses.
There's a fairly clear hierarchy here. If you reflect it in the database, then you'd have the following:
Address holding a foreign key to ZipCode.
ZipCode holding a foreign key to City.
City holding a foreign key to State.
So your design for State, City, and ZipCode look right; you should complete it by choosing Option 3.
Here are some benefits to this design:
You'll avoid update anomalies. You won't ever get into a situation where an Address holds/is related to a Zip Code from California while also holding/being related to the state of Wyoming.
You'll not be holding the string "Illinois" over and over again - aside from saving space, if you realise you accidentally typed "Ilinois" three years down the line, you won't need to carry out a huge update script on the Address table of your live database to correct the problem.
If a state border changed and a city which used to be a part of Arizona became part of New Mexico (OK, this is unlikely, but bear with me for the sake of sticking with your example!), you'd only have to update the foreign key on a single record in the City table.
If there's ever a different need for this same data (Reporting? Business intelligence/analytics? A new website feature?), having a solid structure like this with each data item held in only one place and without spurious foreign keys will make it clear which data to use, will help avoid the need for time consuming and potentially problematic data cleansing, and will reduce development time. Duplicated and inconsistent data in source systems takes up a huge amount of my time as a business intelligence/data warehousing developer.
You have the right idea in looking ahead and thinking about whether your current database design can stand up to your website's growth. The sooner you resolve issues like this, the easier they'll be to change and the less disruption you're likely to suffer.
If you're currently working with something more like Option 2, then I'm guessing you might well have used a similar pattern elsewhere in your database. If this is the case, and you'd like to avoid the issues I've mentioned above (and others), then it's really worth doing some reading or training on database design, and specifically how to carry out normalization.