Комментарии 24
Дефективные там лонги. Ибо только со знаком. Некоторые айдишники не влезают в диапазон.
Только что проверил… Да, при вставке 0xFFFFFFFFFFFFFFFF в базу через MongoInt64 оно обрезается до 0x7FFFFFFFFFFFFFFF.
Возможно, при вставке из 64-битной версии PHP с native_long=1 ситуация будет иная. Не могу сейчас проверить.
Возможно, при вставке из 64-битной версии PHP с native_long=1 ситуация будет иная. Не могу сейчас проверить.
Не будет. В самом BSON не предусмотренные беззнаковые целые.
Битовое представление 0xFFFFFFFFFFFFFFFF и -0x8000000000000000 идентично.
Поэтому если драйвер просто передает 0xFFFFFFFFFFFFFFFF как есть (а драйвер, насколько я знаю, формирует для передачи в базу сразу BSON), то и проблем быть не должно.
Поэтому если драйвер просто передает 0xFFFFFFFFFFFFFFFF как есть (а драйвер, насколько я знаю, формирует для передачи в базу сразу BSON), то и проблем быть не должно.
Ждем результатов тестов. С руби такой фокус не прокатывает.
<?php
$x = -0x7FFFFFFFFFFFFFFF;
$m = new Mongo();
$c = $m->selectCollection("test", "test64");
echo $x."\n";
$c->remove();
$c->insert(array("var" => $x));
$r = $c->findOne();
var_dump($r["var"]);
?>Результат:
-9223372036854775807 int(-9223372036854775807)
Я думаю понятно, что -0x7FFFFFFFFFFFFFFF = 0x8000000000000000
Хотел использовать монго в своём проекте, но то, что оно не поддерживает unsigned int/long, просто выводит меня из себя. Что, если мне нужно хранить большие числа, и затем сортировать результат по ним? Если я запишу 18446744073709551616 (0xFFFFFFFFFFFFFFFF), а в базе останется -9223372036854775808 (-0x8000000000000000), то и сортировка будет происходить по signed long, т.е. неправильно. Наверное буду искать другую бд.
скажите, а не логичнее ли длинные числа, над которыми не надо проводить арифметические операции, и которые берутся с внешних сервисов (а значит в какой-то момент времени могут стать к примеру 12-ти байтовыми, или вовсе не числами) хранить в строке?
Ну, с числами вроде как быстрее работает. Индексы меньше весят. И другие мелкие приятности.
У меня ситуация иная, чем у автора оригинала.
Мне нужно хранить в базе некоторую статистику, значения которой могут не помещаться в 32 бита.
И арифметические операции производить над ней надо)
Мне нужно хранить в базе некоторую статистику, значения которой могут не помещаться в 32 бита.
И арифметические операции производить над ней надо)
Простите, но позвольте полюбопытствовать, что это за статистика?)
Не могу раскрывать подробностей.
В общих чертах: в базе хранятся результаты некоторых операций, которые имеют несколько числовых параметров.
По некоторым критериям записи из базы надо агрегировать, считая сумму некоторых из параметров. Сумма легко может вылезти за границы 32 бит.
В общих чертах: в базе хранятся результаты некоторых операций, которые имеют несколько числовых параметров.
По некоторым критериям записи из базы надо агрегировать, считая сумму некоторых из параметров. Сумма легко может вылезти за границы 32 бит.
Масштабируйте тогда значения.
И вообще, работая с такими суммами — как вы переполнения контролируете?
Или вы числа в отсортированном порядке складываете?
Есть задачка из универского курса вычислительной математики: что будет точнее —
a1 = 1.64493396684726
a2 = 1.64493396684823
это я к тому что порядок суммирования — важная штука.
В моем примере работа с малыми числами, а в случае больших, как у вас — это еще актуальнее.
И вообще, работая с такими суммами — как вы переполнения контролируете?
Или вы числа в отсортированном порядке складываете?
Есть задачка из универского курса вычислительной математики: что будет точнее —
j1 = 1:1:10000000;
a1 = sum( 1./ (j1.^2) );
j2 = 10000000:-1:1;
a2 = sum( 1./ (j2.^2) );
a1 = 1.64493396684726
a2 = 1.64493396684823
это я к тому что порядок суммирования — важная штука.
В моем примере работа с малыми числами, а в случае больших, как у вас — это еще актуальнее.
Порядок суммирования имеет значение при сложении чисел с плавающей запятой из-за изначальной неточности этих чисел.
У меня все числа целые.
Далее, у меня сумма чисел будет заведомо укладываться в 64 бита. А вот в 32 не всегда. Поэтому мою проблему статья решает на 100%, осталось дождаться переезда на новый сервер с установкой 64-битной системы (сейчас на 32-битной фре сижу).
У меня все числа целые.
Далее, у меня сумма чисел будет заведомо укладываться в 64 бита. А вот в 32 не всегда. Поэтому мою проблему статья решает на 100%, осталось дождаться переезда на новый сервер с установкой 64-битной системы (сейчас на 32-битной фре сижу).
Хммм, а если использовать не десятичную систему счисления? Операций добавится, но по размерам влезете однозначно.
Далеко не всегда. Ну вот я использую MongoInt64 для хранения ID пользователя в соцсети, с которой работает наше приложение. Естественно, по этому полю нужен уникальный ключ и очень много выборок из базы по этому ключу. А индекс по такому полю построить намного дешевле, чем по строке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
64-битные целые в MongoDB