Gary provides a simple and effective solution. He also states that he also has added additional tables to handle unique entity data. There may be a couple more issues you may want to think about. First, I am not sure what you actually need this structure for. How you intend to use it may dictate some of your solution. Consider what is unique here. Only zip codes. Yes States are also unique but their names are not. They may also be used as county and city/town names. Counties are similar. They are unique to a state but Counties with the same name are found in multiple states. There names also show up as cities/towns. City names will show un in many states and on rare occassions can show up more than once in the same state. If I have not given you enough to think about Louisanna does not have counties. They have parishes so you may want/need an identifier for that, just something else to think about. Instead of using an identify column (I assume generated) as the primary key, you might consider using something like a geocode or Dunn&Bradstreet identifier as your primary key to guaranty uniqueness. In the long run this may be simpler. You can then relate them hierarchically, rationally or both. 🙂