MySql и плавающий или удвоить мой номер, когда я обновляю его по запросу из переполнения стека
Мне нравится очень точно хранить широты и долготы в моей базе данных MySql с InnoDB. Однако, float не предлагал достаточно внутренних десятичных разрядов, поэтому я переключился на double. Я немного удивился, но MySql принял double с размером до 30, поэтому я использовал double (30,27), потому что нужны только 3 обычных места, а остальные должны быть за запятой.
Хорошо в MySql, который работал до сих пор, и с другой стороны, я получаю плавающие над json_decode, и когда я повторяю их, есть до 18 или 19 мест после запятой. Так что даже здесь все как положено.
Но когда я строю запрос на обновление, чтобы заполнить пустые двойные поля (двойные 30/27), он просто заполняет все цифры нулями, за исключением первых 9 цифр.
Или иногда нарушает начало правила из 7. цифры со строкой 9.
Например, когда я обновляю 47.2608691999999877 в mysql — неважно, для каждого скрипта или для PhpMyAdmin, после нажатия кнопки сохранения 47.260869199999990000000000000 появляется в таблице, где должно появиться 47.260869199999987700000000000 или
11.396251100000000633, так как обновление в таблице дает мне
+11,396251100000000000000000000
Похоже, что он игнорирует возможные места, начиная с 7, или иногда заполняет его 9-ми, но в большинстве случаев это просто нули.
Может кто-нибудь дать мне совет, чтобы решить эту проблему, пожалуйста?
Помните, я также получил проблему с PHPMyAdmin, но сделан из PHP. Теперь я не уверен, что это проблема MySQL или PHP.
Спасибо
Так например
Я MYSql я могу хранить это легко, например, PHPMyAdmin:
Решение
Заметьте, как DOUBLE (30, 27) имел смысл для 16-17 значащих цифр, а затем стал бесполезным?
FLOAT имеет 24 бит точности. Этого достаточно для примерно 7 значащих цифр. В частности, для широты и долготы это достаточно точно, чтобы пройти в пределах 1,7 метра (5,6 фута). Для большинства применений lat / lng этого достаточно. Таким образом, на самом деле не имеет значения, что есть ошибка округления при вставке (преобразование из десятичной в двоичную) и другая ошибка при чтении (преобразование обратно в десятичную).
DOUBLE обладает 53 битами точности, около 16 значащих цифр — 3,5 нм с севера на юг или с востока на запад!
DOUBLE (30, 27) — при вставке говорят: (1) округлить до 27 десятичных знаков, (2) округлить до 53 бит точности. При чтении происходит обратное, что приводит к странным путаницам, которые у вас есть.
Я никогда не видел обоснованной необходимости использования (M, N) на FLOAT или DOUBLE. Не делай этого.
Для DECIMAL (M, N) вы храните именно так что будет соответствовать N десятичных знаков. Для целей широты / долготы, рассмотрим DECIMAL (6,4) для широты и (7,4) для долготы — 16 метров (52 фута). Или, для большей точности, (8,6) и (9,6) — 16 см (6 дюймов).
Также обратите внимание, что FLOAT занимает 4 байта (всегда), DOUBLE: 8, DECIMAL (6,4): 3, (7,4): 4, (8,6): 4, (9,6): 5. Если у вас есть миллиарды записей lat / lng, байты памяти складываются.
Другие решения
Ваш скрипт и PHPMyAdmin написали на PHP, который использует точность для дисплей числа с плавающей точкой, но mysql и php обрабатывают числа максимально точно.
Попробуйте изменить настройки точности .ini: http://php.net/manual/ru/ini.core.php#ini.precision
Я бы не стал доверять никаким числам с плавающей запятой для хранения в широте / долготе, вы почти гарантированно сразу же получите ошибки округления. Числа с плавающей точкой просто не так точны.
Рассматривали ли вы целое число с фиксированной точкой (47.2608691999999877 становится 472608691999999877 путем умножения и деления на 10000000000000000, когда это требуется для отображения / возврата из ввода (или даже просто выполнения строковой операции для отображения.)
Числа этого масштаба должны довольно удобно помещаться в диапазоне 64-битного целого числа (черт, вы даже можете получить 17-е десятичное место и при этом быть в порядке: P.)