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

#sql #mongodb #schema #geocoding #database

#sql #mongodb #схема #геокодирование #База данных

Вопрос:

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

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

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

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

Ответ №1:

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

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

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