Самый эффективный способ хранения геолокации в базе данных - PullRequest
5 голосов
/ 16 ноября 2008

Я знаю, что у postgres есть тип данных для хранения географических координат. Но я ищу решение, независимое от СУБД. В настоящее время я использую Decimal (25,20) в MySQL. Возможно, я буду использовать эти данные для поиска этих местоположений на основе заданного расстояния от заданного местоположения позже. Каков наилучший подход для хранения таких данных?

Ответы [ 6 ]

6 голосов
/ 16 ноября 2008

Еще один хороший метод - умножить значения на константу и сохранить их как целочисленные значения. Использование только целых чисел также может помочь ускорить вычисления.

Если вам не нужна серьезная точность, вам действительно нужно хранить только 5+ значений после десятичной точки.

Эта Спецификация хранения данных широты и долготы дает диаграмму, которая показывает точность по сравнению с десятичными разрядами.

# decmal places, example, precision
5    51.22135    ± 0.8 m
6   50.895132   ± 0.08 m

7 будет 8 мм или около 0,314 дюйма.

1 голос
/ 16 ноября 2008

ответ vfilby , вероятно, является лучшим, однако многие СУРБД лучше поддерживают индексацию символьных полей, чем индексирование плотных целочисленных (или с плавающей запятой) полей.

Только по этой причине я мог бы рекомендовать сначала преобразовать данные: если вы хотите найти значения «рядом» с другим значением, вам дополнительно понадобится функция, которая сохраняет это - возможно, путем преобразования в base36 и _ - padding до десятичной точки, но если вам просто нужно точное совпадение, подойдет почти любая функция быстрого хеширования.

Опять же: если у вас мало данных или вы не используете СУБД, подобную этой, сделайте то, что vfilby предложил .

1 голос
/ 16 ноября 2008

AFAIK, MS SQL Server 2008 поддерживает геолокацию как тип данных. Я знаю, что вы используете MySQL, но подумал, что упомяну об этом по этому вопросу.

1 голос
/ 16 ноября 2008

Стандарт здесь . Хотя это слишком много для простого варианта использования, такого как ваш, он может дать вам некоторые идеи о том, почему на самом деле может быть лучше пойти и использовать некоторые OGC-совместимые пакеты, которые есть у многих баз данных в настоящее время, даже MySQL .

В противном случае и при условии, что вы реализуете алгоритмы для вычисления расстояний, любое число с плавающей запятой, имеющее необходимую точность, будет работать.

0 голосов
/ 16 ноября 2008

Я всегда использовал 4-байтовые столбцы с плавающей запятой для сохранения широты и долготы, потому что погрешность в точности намного меньше точности используемых нами устройств. Это может быть не так с вашим приложением, но если это так, вы не можете получить гораздо более независимую от СУБД, чем с плавающей точкой.

0 голосов
/ 16 ноября 2008

После @ ответа vfilby почему бы не сохранить две половины числа как два отдельных типа int?

...