geocoding database provider(sql, nosql) and schema

Companies like Yahoo, Google, MS provide geocoding services. I'd like to know what is the best way to organize the backend for such services - what is the optimal solution in terms of database provider(SQL vs NOSQL) and database schema.

Some providers use Extensible Address Language (xAL) to describe an entity in the geocoding response. xAL has more than 30 data elements. Google geocoding API has abou开发者_如何转开发t 20 data elements.

So in case of SQL database there will be 20-30 tables with mostly one-to-many relationships via foreign keys?

What about NOSQL databases, like MongoDB. How would one organize such a database? lots of collections for each data element, similar to SQL? One collection where each document completely describes given entity in the address space?

It's hard to say... It depends on what you need to do with the data in term of analysis and caching.

I had to deal with geo coordinates. But our app is very simple and we don't need to manipulate the geolocations in DB, simply store and retrieve. So I simply store start and end points in 2 columns of each route and a polyline in a binary column, with a few milestones being saved in a dedicated SQL table.

But for an advanced use of our APP we considered using this: https://simplegeo.com/