поставщик базы геокодирования (sql, nosql) и схема

Question

Такие компании, как Yahoo, Google, MS, предоставляют услуги геокодирования. Я хотел бы знать, каков наилучший способ организации бэкэнда для таких служб - каково оптимальное решение с точки зрения поставщика базы данных (SQL против NOSQL) и схемы базы данных.

Некоторые провайдеры используют Extensible Address Language (xAL) для описания объекта в ответе геокодирования. xAL имеет более 30 элементов данных. Google Geocoding API имеет около 20 элементов данных.

Таким образом, в случае базы данных SQL будет 20-30 таблиц, в основном с отношениями один-ко-многим через внешние ключи?

Как насчет баз данных NOSQL, таких как MongoDB. Как организовать такую ​​базу данных? много коллекций для каждого элемента данных, похожих на SQL? Одна коллекция, где каждый документ полностью описывает данную сущность в адресном пространстве?

Answer 1

Трудно сказать ... Это зависит от того, что вам нужно делать с данными в плане анализа и кэширования.

Мне пришлось иметь дело с географическими координатами. Но наше приложение очень простое, и нам не нужно манипулировать геолокацией в БД, просто хранить и получать. Поэтому я просто храню начальную и конечную точки в 2 столбцах каждого маршрута и ломаную линию в двоичном столбце, а несколько этапов сохраняются в отдельной таблице SQL.

Но для расширенного использования нашего приложения мы решили использовать это: https://simplegeo.com/