Database Design: saving Google Maps data [closed] - mysql

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
SEE: http://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&sensor=false
I'm using MySQL.
Given a partial or complete address, the Google Map API will return something like this:
"address_components" : [
{
"long_name" : "1600",
"short_name" : "1600",
"types" : [ "street_number" ]
},
{
"long_name" : "Amphitheatre Pkwy",
"short_name" : "Amphitheatre Pkwy",
"types" : [ "route" ]
},
{
"long_name" : "Mountain View",
"short_name" : "Mountain View",
"types" : [ "locality", "political" ]
},
{
"long_name" : "Santa Clara",
"short_name" : "Santa Clara",
"types" : [ "administrative_area_level_2", "political" ]
},
{
"long_name" : "California",
"short_name" : "CA",
"types" : [ "administrative_area_level_1", "political" ]
},
{
"long_name" : "United States",
"short_name" : "US",
"types" : [ "country", "political" ]
},
{
"long_name" : "94043",
"short_name" : "94043",
"types" : [ "postal_code" ]
}
]
Assume I am developing an application wherein:
account owners can specify their location, and
search by location is supported
How should I store the address components I get from Google so that I can query for the following:
How many account owners in a particular country?
How many account owners in a particular state?
How many account owners in a particular ZIP/postal code?
etc.
One very easy way is to store individual address components in one table:
TABLE: account
- account_id (PK)
- street_number
- route
- locality
- administrative_area_level_2
- administrative_area_level_1
- country
- postal_code
I'll just leave blank whatever information Google does not provide (e.g. if account owner did not provide a street number, then the Google API also won't return the street_number). I think this would be the simplest to query. However, this data won't be normalized.
Alternatively, I could could design the database to have multiple tables, for example:
TABLE: country
- country_id (PK)
- name
TABLE: administrative_area_level_1
- administrative_area_level_1_id (PK)
- country_id (FK)
- name
... and so on
This will probably normalize the data, but might be a pain to query. Also, missing information might also cause some problems. For example, what if Google returns country and administrative_area_level_2, skipping administrative_area_level_1 (I'm not sure if this is even possible)? administrative_area_level_2 would require a administrative_area_level_1_id as its FK -- and without it, the model breaks.
Another idea might be to use a nested set or adjacency model. The data would be normalized and would probably be able to deal better with missing information.
My gut feeling is that the simplest model -- the one allowing redundant data -- is the best option for me. The data is not coming from me, it's coming from Google and I think I only need the data so I can do these search-by-location searches. Maybe I won't run into anomalies?
Any suggestions on how to model this?

Answer 1

Before you start worrying about how to model the data you retrieve from Google Maps, you might want to check out the terms of service first, at http://code.google.com/apis/maps/terms.html.
Particularly take note of 10.1.3 (a):
"You must not copy, translate, modify, or create a derivative work (including creating or contributing to a database) of, or publicly display any Content or any part thereof..."
I'd say that pretty much explicitly prohibits the kind of application you're trying to build. If you want to query the address information Google has about one of your account owners, you have to do it using Google's APIs - not copying their data and doing it in your own application.