地理编码数据库提供程序（sql、nosql）和架构
雅虎、谷歌、微软等公司提供地理编码服务。我想知道为此类服务组织后端的最佳方式是什么 - 数据库提供程序（SQL 与 NOSQL）和数据库模式方面的最佳解决方案是什么。
某些提供商使用可扩展地址语言 (xAL) 来描述地理编码响应中的实体。 xAL 有 30 多个数据元素。 Google 地理编码 API 有大约 20 个数据元素。
那么，对于 SQL 数据库，将有 20-30 个表，其中大部分通过外键建立一对多关系？
NOSQL 数据库怎么样，比如 MongoDB。如何组织这样一个数据库？每个数据元素有很多集合，类似于 SQL？每个文档都完整描述地址空间中给定实体的一个集合？
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 about 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很难说......这取决于您需要在分析和缓存方面对数据做什么。
我必须处理地理坐标。但我们的应用程序非常简单，我们不需要操纵数据库中的地理位置，只需存储和检索即可。因此，我只是将起点和终点存储在每条路线的 2 列中，并将折线存储在二进制列中，并将一些里程碑保存在专用 SQL 表中。
但为了高级使用我们的应用程序，我们考虑使用：https://simplegeo.com/
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/