Какой идеальный тип данных использовать при хранении широты / долготы в базе данных MySQL?
Прежде всего, самая важная зависимость каждой динамически связанной программы - это компоновщик. Все библиотеки должны соответствовать версии компоновщика.
Давайте возьмем простой пример: у меня есть система новостей ubuntu, в которой я запускаю некоторую программу (в моем случае это компилятор D - ldc2). Я хотел бы запустить его на старой CentOS, но из-за старой библиотеки glibc это невозможно. Я получил
ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)
ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)
Мне нужно скопировать все зависимости от ubuntu до centos. Правильный метод следующий:
Сначала давайте проверим все зависимости:
ldd ldc2-1.5.0-linux-x86_64/bin/ldc2
linux-vdso.so.1 => (0x00007ffebad3f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f965f597000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f965f378000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f965f15b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f965ef57000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f965ec01000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f965e9ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f965e60a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f965f79f000)
linux-vdso.so.1 не является реальной библиотекой, и нам не нужно заботиться об этом.
/lib64/ld-linux-x86-64.so.2 является компоновщиком, который используется linux do, связывает исполняемый файл со всеми динамическими библиотеками.
Остальные файлы являются реальными библиотеками, и все они вместе с компоновщиком должны быть скопированы где-то в центрах.
Предположим, что все библиотеки и компоновщики находятся в каталоге «/ mylibs».
ld-linux-x86-64.so.2 - как я уже сказал, - это компоновщик. Это не динамическая библиотека, а статический исполняемый файл. Вы можете запустить его и увидеть, что у него даже есть некоторые параметры, например, -library-path (я вернусь к нему).
В linux динамически связанная программа может быть отправлена только по ее имени, например
/bin/ldc2
Linux загружает такую программу в ОЗУ и проверяет, какой компоновщик установлен для нее. Обычно в 64-битной системе это /lib64/ld-linux-x86-64.so.2 (в вашей файловой системе это символическая ссылка на реальный исполняемый файл). Затем linux запускает компоновщик и загружает динамические библиотеки.
Вы также можете немного изменить это и сделать такой трюк:
/mylibs/ld-linux-x86-64.so.2 /bin/ldc2
Это метод принудительного использования linux конкретный линкер.
И теперь мы можем вернуться к упомянутому ранее параметру -library-path
/mylibs/ld-linux-x86-64.so.2 --library-path /mylibs /bin/ldc2
Он запустит ldc2 и загрузит динамические библиотеки из /mylibs.
Это метод вызова исполняемого файла с выбранными (не системными) библиотеками.
9 ответов
FLOAT должен дать Вам всю точность, в которой Вы нуждаетесь и лучше для функций сравнения, чем хранение каждой координаты как строка и т.п.
, Если Ваша версия MySQL ранее, чем 5.0.3, Вы, возможно, должны принять во внимание определенные ошибки сравнения с плавающей точкой как бы то ни было.
До MySQL 5.0.3, столбцы DECIMAL снабжают значения точной точностью, потому что они представлены как строки, но вычисления на Десятичных значениях сделаны с помощью операций с плавающей точкой. С 5.0.3, MySQL выполняет ДЕСЯТИЧНЫЕ операции с точностью 64 десятичных цифр, которые должны решить наиболее распространенные проблемы погрешности когда дело доходит до столбцов DECIMAL
Вычисления Lat Long требуют точности, так используйте некоторый тип десятичного типа и сделайте точность по крайней мере 2 выше, чем число, которое Вы сохраните для выполнения математических вычислений. Я не знаю о своих sql типах данных, но у людей SQL-сервера часто используют плавание или реальный вместо десятичного числа и попадают в беду, потому что это, оцененные числа не реальные. Поэтому просто удостоверьтесь тип данных, который Вы используете, истинный десятичный тип и не плавающий десятичный тип, и необходимо быть в порядке.
Когда я сделал это для базы данных навигации, созданной из ARINC424, я сделал изрядное количество тестирования и оглядывания назад на код, я использовал ДЕСЯТИЧНОЕ ЧИСЛО (18,12) (На самом деле ЧИСЛОВОЕ (18,12), потому что это был firebird).
Плавания и удваиваются, не так точны и может привести к погрешностям округления, которые могут быть очень плохой вещью. Я не могу помнить, нашел ли я какие-либо реальные данные, которые имели проблемы - но я вполне уверен, что неспособность сохранить точно в плавании или двойном могла вызвать проблемы
Дело в том, что при использовании градусов или радианов мы знаем диапазон значений - и для дробной части нужно большинство цифр.
MySQL Spatial Extensions является хорошей альтернативой, потому что они следуют Модель Геометрии OpenGIS. Я не использовал их, потому что я должен был сохранить свою базу данных портативной.
Пространственные Расширения MySQL являются наилучшим вариантом, потому что у Вас есть полный список пространственных операторов и индексов в Вашем распоряжении. Пространственный индекс позволит Вам выполнять основанные на расстоянии вычисления очень быстро. Следует иметь в виду, что с 6,0, Пространственное Расширение является все еще неполным. Я не подавляю MySQL Spatial, только сообщая ловушек, прежде чем Вы станете слишком далекими вперед на этом.
, Если Вы имеете дело строго с точками и только функцией РАССТОЯНИЯ, это прекрасно. Если необходимо сделать какие-либо вычисления с Полигонами, Строками или Буферизированными Точками, пространственные операторы не обеспечивают точные результаты, если Вы не используете "связать" оператор. Посмотрите предупреждение наверху 21.5.6 . Отношения те, которые содержат, в, или пересекаются, используют MBR, не форму точной геометрии (т.е. Эллипс рассматривают как Прямоугольник).
кроме того, расстояния в MySQL Spatial находятся в тех же единицах как Ваша первая геометрия. Это означает, используете ли Вы Десятичные градусы, тогда Ваши дистанционные измерения находятся в Десятичных градусах. Это сделает очень трудным получить точные результаты, поскольку Вы получаете furthur от экватора.
Мы храним широту/долготу X 1,000,000 в нашей базе данных оракула, поскольку ЧИСЛА для предотвращения округляют ошибки с, удваивается.
, Учитывая, что широта/долгота к 6-му десятичному разряду была точностью на 10 см, которая была всем, которое нам было нужно. Много других баз данных также хранят lat/long к 6-му десятичному разряду.
Пространственные функции в PostGIS намного более функциональны (т.е. не ограниченные к операциям BBOX), чем те в MySQL пространственные функции. Проверьте его: текст ссылки
Я предлагаю, чтобы Вы использовали Тип данных float для SQL Server.
в зависимости от вашего приложения, я предлагаю использовать пространственные ключи FLOAT (9,6)
, которые предоставят вам больше возможностей, но в производственных тестах float намного быстрее, чем пространственные ключи. (0,01 VS 0,001 в AVG)