Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4      [все]
 String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
Вот есть модель, которая проецируется в базу данных и есть у нее некое поле, пусть будет state
В базе данных поле имеет тип int и в модели на всего возможные значения заведены константы:


const STATE_ACCEPTED = 10;
const STATE_REJECTED = 20;
const STATE_UNKNOWN = 30;

Данные хранятся в mongodb, которая не имеет ENUM типов, поэтому решил использовать числовые для более оптимальной работы СУБД. Так я делал всегда и думал, что это правильно. Но недавно в команде появился человек, которого очень смутило то, что константы числовые и анализировать базу данных ему не удобно (он не аналитик, он программист), типа с текстовыми было бы проще.

Лично я считаю, что база данных в первую очередь для приложения, а не человека и должна быть оптимизирована под работу приложения. А если нужно раз в год туда залезти что-то посмотреть, то можно и в коде подсмотреть значения констант.

Ну и отдельный разговор, почему 10-20-30, а не 1-2-3. У меня была какая-то мысль, что при таком подходе можно добавить константу "между" существующих, это касается только лаконичности кода.

Что думаете?
24 май 19, 10:46    [21892857]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 780
Hett,

дело вкуса. С одной стороны оперировать числами не удобно (лучше видеть описание констант). С другой стороны проблема быстродействия. Mongo всё равно - строка или число?
24 май 19, 11:19    [21892926]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
KreatorXXI
Hett,

дело вкуса. С одной стороны оперировать числами не удобно (лучше видеть описание констант). С другой стороны проблема быстродействия. Mongo всё равно - строка или число?


Количество данных в любом случае больше. Можно использовать 32-битный интерджер (4 байта), с другой стороны получается 8 символов, даже точно не уверен, сколько это займет памяти. Думаю как минимум байт 12 (4 под длину, + 2 байта на каждый символ?).
Как это будет в индексах выглядеть тоже большой вопрос. Особенно если поле участвует в нескольких составных индексах.
24 май 19, 11:25    [21892935]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Aleksandr Sharahov
Member

Откуда: Москва
Сообщений: 1755
Думаю римские цифры были бы нагляднее,
сразу же видно сколько там палок: одна, две, или три.

Хотя бухгалтер во мне, гад, просит сумму прописью.
24 май 19, 11:26    [21892939]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Hett
типа с текстовыми было бы проще

Дай ему таблицу с кодами и названиями, ну и пусть дальше сам джойнит, раз нравится. Заодно справочник констант сделаешь.
24 май 19, 11:56    [21892987]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
alex55555
Hett
типа с текстовыми было бы проще

Дай ему таблицу с кодами и названиями, ну и пусть дальше сам джойнит, раз нравится. Заодно справочник констант сделаешь.


Программист жеж, знает где найти константы.
24 май 19, 12:11    [21893001]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
Ну и отдельный разговор, почему 10-20-30, а не 1-2-3. У меня была какая-то мысль, что при таком подходе можно добавить константу "между" существующих, это касается только лаконичности кода.

Что думаете?

Я не знаток Монго. Но обычно с точки зрения баз данных - решительно пофиг какие ключи хранить. Числа
и строки (CHAR/VARCHAR) имеют почти одинаковые накладные расходы на хранение. Числа нужны только
для sequence.

Если интересует эстетика - то я-бы предложил завести краткие натуральние STATE KEYS. Типа

const STATE_ACCEPTED = "A";
const STATE_REJECTED = "R";
const STATE_UNKNOWN = "U";

Это даст возможность писать mongo queries "по памяти". Тоесть не заглядывае в справочник.
Про экономию места не стоит беспокоиться. Ключи на фоне ихнего binary-json будут каплей в море.

Вставлять промежуточные значения между ключами - это старая идея как из Бейсика. Типа ключ с номером 15
будет по рангу стоять между STATE_ACCEPTED и STATE_REJECTED. Но какой в этом смысл? Если в системе эти ранги есть.
Если нет - то пофиг.
24 май 19, 12:20    [21893015]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
Поддержу предыдущего оратора. Если нет нужды сравнивать на больше-меньше, то строки удобнее. Оверхед на строку в 8 символов (а это в среднем даже меньше чем размер GUID) по сравнению с целым числом ничтожен, будь это хоть монго, хоть какая-нибудь другая БД. Дотнетовский драйвер для монго позволяет настроить сериализацию enum-ов - cохранять их числом или строкой.
24 май 19, 12:52    [21893054]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
Поди еще айпи адреса текстом храните?
24 май 19, 13:06    [21893073]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
Hett,

Почему бы нет. Его обязательно в int паковать - без этого никак? Так можно вообще всю запись целиком в один binary упаковать и так хранить - представляешь, какая экономия будет.
24 май 19, 13:17    [21893085]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
fkthat
Hett,

Почему бы нет. Его обязательно в int паковать - без этого никак? Так можно вообще всю запись целиком в один binary упаковать и так хранить - представляешь, какая экономия будет.


Зачем фантазируете? Давайте тогда объект в джесон завернем и сохраним в varchar? Я могу тоже какую-нибудь чушь сморозить, будем в остроумии соревноваться?

По существу: ip в int и даже в bitint уже не пакуются давно в свете появления ipv6.
А разница в том, сколько памяти будет израсходовано, особенно если это поле присутствует в нескольких индексах. Часто используемые индексы тем более в ОЗУ желательны.

ps^ Я не говорю про поиск в подсетях, тут то даже спорить было бы не о чем. Допустим это нам точно не понадобится.
24 май 19, 13:23    [21893092]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
Hett,

А если у меня IP только в целях логирования/аудита хранится - мне его тоже в бинарном виде хранить надо для экономии? Кстати, не знаю где как, но MSSQL уже поддерживает json поля, а поля с XML так вообще уже почти 15 лет как.
24 май 19, 13:44    [21893115]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
fkthat
Hett,

А если у меня IP только в целях логирования/аудита хранится - мне его тоже в бинарном виде хранить надо для экономии? Кстати, не знаю где как, но MSSQL уже поддерживает json поля, а поля с XML так вообще уже почти 15 лет как.


Это IP - это не фрагмент текста и хранится в отдельном поле, то почему бы не хранить его в бинарном виде?
24 май 19, 13:52    [21893120]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
Hett,

А в чем, в общем-то, преимущество хранения в бинарном виде, кроме размера поля?
24 май 19, 16:03    [21893266]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
90% надо смотреть от юзкейса. Если например мы храним целый инстаграм картинок - то разумно брать BLOB
или внешнее файловое хранение.

Для IP адресов. Ну … если 99% они используются для печати в лог-файле (а там они представлены в принтабельнов виде)
то можно сразу их складывать в строку. Или для поисковых операций по документу. Где в сущности строки даже легче.
Всё как-то гомогенно получается.

Хранить как int в документно-ориентированной БД... ну не знаю. Рискну предположить что будет польза будет варироваться
от "никакой пользы" до "ненужные преобразования для прочтения человеком на экране".
24 май 19, 16:11    [21893270]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
mayton
90% надо смотреть от юзкейса.

+100500
24 май 19, 16:15    [21893274]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
alex55555
Member

Откуда:
Сообщений: 2129
fkthat
А в чем, в общем-то, преимущество хранения в бинарном виде, кроме размера поля?

Размер влияет на потребление памяти, а память влияет на скорость работы. Поэтому пари меньшем размере больше индексов в память поместится, значит в среднем будет больше скорость. Плюс само сравнение узлов в дереве быстрее для Int делать, нежели для строки - опять ускорение. Плюс коррекция данных, то есть либо они парсятся в int, либо нет, своего рода валидация.

Хотя да, можно забить на всё это. Но такую привычку лучше не тренировать.
25 май 19, 10:46    [21893671]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
alex55555,

Да эта тема "int vs guid" обжевана повсюду уже мульон раз - в теории guid в четыре раза меньше, но на практике разницы именно из-за размера никакой.
25 май 19, 11:45    [21893702]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
"в четыре раза больше", конечно.
25 май 19, 11:56    [21893713]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
miksoft
Member

Откуда:
Сообщений: 37672
fkthat
"в четыре раза больше", конечно.
у кого как, некоторые хранят guid-ы в VARCHAR(36) в виде строки '22345200-abe8-4f60-90c8-0d43c5f6c0f6'.
25 май 19, 12:06    [21893719]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
fkthat
alex55555,

Да эта тема "int vs guid" обжевана повсюду уже мульон раз - в теории guid в четыре раза меньше, но на практике разницы именно из-за размера никакой.

GUID используется в распределённых и JMS системах где вам нужно гарантировать уникальность ключа
при отсутствии глобального распределённого объекта типа sequence. Поэтому выбор GUID - это не "количественный"
а архитектурный выбор.

На интах вы такое не сможете построить.
25 май 19, 12:12    [21893724]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
miksoft
fkthat
"в четыре раза больше", конечно.
у кого как, некоторые хранят guid-ы в VARCHAR(36) в виде строки '22345200-abe8-4f60-90c8-0d43c5f6c0f6'.


Эти некоторые уже выше отписались. Если IP хранят в виде строки, то GUID/UUID аналогично, подозреваю.
25 май 19, 15:29    [21893822]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
Это я к тому, что если уж говорить про эти ваши GUID/UUID, то опять же в том контексте, как его хранить, бинарно (с обертками субд) или строкой. А сравнивать его с Int смысла нет, думаю это очевидно.
25 май 19, 15:30    [21893825]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58418
Блог
Hett
Что думаете?

В принципе, мнемокоды, конечно, более наглядны, нежели числа - скажем, RUB понятнее, чем 643, да и поле GENDER с возможными значениями 0/1 не сказать чтобы сверхудобно. С другой стороны, числа удобны тем, что в них существует логичный порядок - это иногда удобно применять, например, для статусов, а в булёвых полях - коих обычно больше, чем всех остальных вместе взятых - 0/1 не требуют гадать, записать ли туда 'Y', 'y', 'yes' или 'да', да и расширение числовых вариантов новыми значениями обычно проходит проще (скажем, если в поле GENDER нужно добавить ещё нейтралов и трансгендеров).

В общем, это больше вопрос вкусов - можно так, можно эдак, но нужно выбрать цельную концепцию, использовать её и адекватно документировать, тогда ни у кого не будет проблем. Всего лишь

SQL> desc dm_lineup

Name         Type       Nullable Default Comments                                                                 
------------ ---------- -------- ------- ------------------------------------------------------------------------ 
OBJ_VER_CODE NUMBER(30)                  # Первичный ключ                                                         
MAP_CODE     NUMBER(30)                  # Карта                                                                  
STATUS       NUMBER(1)           0       Состояние (0 - к выполнению, 1 - выполнена, 2 - не выполнена и не будет) 

и ни у кого не возникает вопросов.

mayton
Но обычно с точки зрения баз данных - решительно пофиг какие ключи хранить. Числа
и строки (CHAR/VARCHAR) имеют почти одинаковые накладные расходы на хранение.

Ну это как-то сильно сказано.

SQL> create table ttt$(i integer, v varchar2(100 char));
Table created

SQL> insert into ttt$ values (1234567890, 'АБВГДЕЁЖЗИ');
1 row inserted

SQL> select i, v, length(i), length(v), dump(i), dump(v) from ttt$;

         I V           LENGTH(I)  LENGTH(V) DUMP(I)                   DUMP(V)
---------- ---------- ---------- ---------- ------------------------- --------------------------------------------------
1234567890 АБВГДЕЁЖЗИ         10         10 Typ=2 Len=6: 197,13,35,57 Typ=1 Len=20: 208,144,208,145,208,146,208,147,208,
                                            ,79,91                    148,208,149,208,129,208,150,208,151,208,152
25 май 19, 19:24    [21893917]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
mayton
GUID используется в распределённых и JMS системах где вам нужно гарантировать уникальность ключа
при отсутствии глобального распределённого объекта типа sequence. Поэтому выбор GUID - это не "количественный"
а архитектурный выбор.

Ну могут быть еще другие резоны. Например, его случайность, и возможность сгенерить ключ записи еще на клиенте до вставки в таблицу. При желании, кстати, guid вполне можно и укоротить. В "мс-овском" гуиде 6 битов всегда одни и те же, остальные просто случайные. Теоретически даже возможна коллизия, но практически она нереальна.
25 май 19, 21:38    [21893950]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6269
fkthat
Hett,

А в чем, в общем-то, преимущество хранения в бинарном виде, кроме размера поля?

В строгой типизации, блиат
25 май 19, 22:28    [21893967]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6269
Свеженький пример 21893157
25 май 19, 22:29    [21893969]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
Siemargl
Свеженький пример 21893157

И при чем тут типизация. Точно так же можно куда-нибудь сохранить вполне себе строготипизированные 8 байтов, а потом рвать волосы на джоппе, что они никак обратно на такие же строготипизированные 4 байта не натягиваются.
25 май 19, 22:44    [21893973]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Для Mongo нет выделенного типа данных Ipv4, Ipv6.

Все равно придется строкой хранить.
25 май 19, 22:47    [21893975]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Для Mongo нет выделенного типа данных Ipv4, Ipv6.

Все равно придется строкой хранить.


Binary еще не проходили?
25 май 19, 22:51    [21893976]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
Для Mongo нет выделенного типа данных Ipv4, Ipv6.

Все равно придется строкой хранить.


Binary еще не проходили?

Покажите как вы будете с этим Binary работать на примере в Mongo.
Создайте несколько документов с полем IPv6-Binary. И положите туда к примеру такие адреса:

::1 
fe80::f42:c2c3:d57:ce60
::192.168.0.1
ff00:: 


Я хочу посмотреть какие усилия вы на это потратите.

P.S. Нет ничего лучше чем постижение истины в примерах.
25 май 19, 23:34    [21893986]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58418
Блог
mayton
Создайте несколько документов с полем IPv6-Binary. И положите туда к примеру такие адреса:

Хм. А в чём проблема?
25 май 19, 23:51    [21893989]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Просто хочу посмотреть вариант с строковым типом и с Binary.
26 май 19, 00:05    [21893992]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58418
Блог
mayton
Просто хочу посмотреть вариант с строковым типом и с Binary.

Я в жизни не видел Mongo, возможно, там какая-то специфика, а из общего представления о binary не вижу в задаче никаких сложностей. Скорее я бы посмотрел, как Вы в случае строковой реализации выдадите правильный результат сравнения адресов ::1 , 0::1 и 0::0::1.
26 май 19, 00:38    [21893996]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
vikkiv
Member

Откуда: London
Сообщений: 2399
softwarer
...Я в жизни не видел Mongo...
https://www.jdoodle.com/online-mongodb-terminal
если есть интерес то для string варианта скопируй туда
version();
db.ips.insert({_id:"::1"});
db.ips.insert({_id:"fe80::f42:c2c3:d57:ce60"});
db.ips.insert({_id:"::192.168.0.1"});
db.ips.insert({_id:"ff00::"});
db.ips.find();
db.ips.drop()
26 май 19, 02:47    [21894003]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
softwarer
Скорее я бы посмотрел, как Вы в случае строковой реализации выдадите правильный результат сравнения адресов ::1 , 0::1 и 0::0::1.


Просто нормализовывать все входные данные перед использованием. Я не топлю за то, чтобы прямо хранить IP как строку, и никак больше. Как уже писали, все должно зависеть от задачи. Можно, наверное, придумать ситуации, когда его вообще лучше по отдельным полям раскидать.
26 май 19, 06:18    [21894013]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton

Я хочу посмотреть какие усилия вы на это потратите.

P.S. Нет ничего лучше чем постижение истины в примерах.



PHP

new MongoBinData(inet_pton($ip), MongoBinData::GENERIC)



Java

       
import org.bson.types.Binary;
         

new Binary(session.getIp().getAddress())
26 май 19, 07:01    [21894015]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
Это с чем я работал (и как). В монгошелле вы конечно не найдете, но это опять же к вопросу зачем в бд лазить руками.
26 май 19, 07:06    [21894016]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
Hett
Это с чем я работал (и как). В монгошелле вы конечно не найдете, но это опять же к вопросу зачем в бд лазить руками.


Когда-то я даже задавался такими вопросами
https://stackoverflow.com/questions/28537599/get-mongobindata-value-from-mongo-shell
26 май 19, 07:10    [21894017]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
softwarer
0::0::1.

Сокращение в адресе может быть только одно.
26 май 19, 07:20    [21894018]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58418
Блог
fkthat
Просто нормализовывать все входные данные перед использованием.

Но ведь нормализация - это по сути to_text(to_binary(string_value)). То есть такой ответ означает, что положить туда "такие адреса" не сложнее, чем любые другие.
26 май 19, 08:39    [21894021]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
alex55555
Member

Откуда:
Сообщений: 2129
fkthat
в теории guid в четыре раза меньше, но на практике разницы именно из-за размера никакой.

И на практике разница может быть 4 раза, и даже может быть 1000 раз. Если в память помещается весь индекс с интами, а с гуидами нет, например.
26 май 19, 12:25    [21894059]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
vikkiv
softwarer
...Я в жизни не видел Mongo...
https://www.jdoodle.com/online-mongodb-terminal
если есть интерес то для string варианта скопируй туда
version();
db.ips.insert({_id:"::1"});
db.ips.insert({_id:"fe80::f42:c2c3:d57:ce60"});
db.ips.insert({_id:"::192.168.0.1"});
db.ips.insert({_id:"ff00::"});
db.ips.find();
db.ips.drop()

Здесь у меня будет несколько дополнений. По юзкейсу. Использовать IPv6 поле как ObjectId. Скорее всего неверно.
Мой юзкейс предполагает что Ipv6 - это атрибут документа. А не уникальный ключ типа Objectid. В качестве вышеуказанного
лучше использовать встроенные в Mongo генераторы которые обеспечат правильный уникальный ключ.

Если конечно мы не делаем базу для обратного nslookup.
26 май 19, 14:47    [21894120]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
Я хочу посмотреть какие усилия вы на это потратите.

P.S. Нет ничего лучше чем постижение истины в примерах.



PHP

new MongoBinData(inet_pton($ip), MongoBinData::GENERIC)



Java

       
import org.bson.types.Binary;
         

new Binary(session.getIp().getAddress())

Типизацию я поддерживаю. Как способ strong check данных на входе и на выходе. Но из личного опыта использования
баз данных я остаюсь убежден в том что строковый формат представления информации на сегодняшний день является
наиболее удобным и универсальным.

Если-бы было наоборот - то в монго мы бы вставляли просто Java-serialized объекты в Externalized или Serialized формате как
в key-value db. Но это не происходит. На практике мы всё равно используем BSON-дерево из различных типов большая часть
всё равно строковые (именно в силу природы вещей, или в силу входных данных). Более того. Все новые. Неизвестные
и неидентифицированные входные данные 99% будут строками. Такой-вот либерализм этой модели.

Строгая типизация всего документа скорее всего противоречила-бы самой идее Mongo-документа или навязывала-бы нам
другое техническое задание где был-бы не Mongo-двигатель а какой-нибудь RDBMS.

Либеральный тип sting даст нам возможность залоггировать IPv4, IPv6, domain-name и более широкий спектр значений.
А проверки на домен значений мы можем сделать на клиенте.

По поводу экономии места и т.п.

Мы живём в эпоху BigData и носителей информации которые стоят меньше цента за мегабайт. И разумно думать скорее
об удобстве программирования и использования. Никто вас не похвалит за экономию 96 (128 - 32 = 96bit) бит информации
за каждый документ. (Да я еще раз делаю упор именно на документ. А документ это порция информации заведомо больше
чем data-row для key-value. Я вангую что документ обычно начинаетяс от 1 килобайта информации)

А вот проблемы при отчотах (два поля для IPv4, IPv6) или кастинг на map-reduce операциях

IPv6 (кстати) при грамотном распределении блоков позволит кстати экономить место на нулях в нотации записи адреса.

Линки по теме
https://docs.mongodb.com/manual/reference/bson-types/#objectid
http://www.ciscopress.com/articles/article.asp?p=2803866
26 май 19, 15:10    [21894132]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
alex55555
fkthat
в теории guid в четыре раза меньше, но на практике разницы именно из-за размера никакой.

И на практике разница может быть 4 раза, и даже может быть 1000 раз. Если в память помещается весь индекс с интами, а с гуидами нет, например.


Для MSSQL если индекс кластерный, то пофиг - потому что там кластерный индекс это вся таблица. Как в других БД я не знаю. И я не бог весть как DBA (не моя сфера), но как-то с трудом представляю, чтобы 4-байтовый индекс в память залез, а вот уже 16-байтовый никак - это, наверное, надо как-то совсем уж на краю лимита памяти балансировать. Проблема с производительностью там возникает cовсем в другом - когда по незнанию используют для кластерного индекса обычный guid, а не "sequential".
26 май 19, 15:56    [21894149]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
vikkiv
пропущено...
https://www.jdoodle.com/online-mongodb-terminal
если есть интерес то для string варианта скопируй туда
version();
db.ips.insert({_id:"::1"});
db.ips.insert({_id:"fe80::f42:c2c3:d57:ce60"});
db.ips.insert({_id:"::192.168.0.1"});
db.ips.insert({_id:"ff00::"});
db.ips.find();
db.ips.drop()

Здесь у меня будет несколько дополнений. По юзкейсу. Использовать IPv6 поле как ObjectId. Скорее всего неверно.
Мой юзкейс предполагает что Ipv6 - это атрибут документа. А не уникальный ключ типа Objectid. В качестве вышеуказанного
лучше использовать встроенные в Mongo генераторы которые обеспечат правильный уникальный ключ.

Если конечно мы не делаем базу для обратного nslookup.


А где здесь ObjectId? Просто строку вставили в качестве _id. Никакого ObjectId здесь нет и в помине.
26 май 19, 16:03    [21894151]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
пропущено...

Здесь у меня будет несколько дополнений. По юзкейсу. Использовать IPv6 поле как ObjectId. Скорее всего неверно.
Мой юзкейс предполагает что Ipv6 - это атрибут документа. А не уникальный ключ типа Objectid. В качестве вышеуказанного
лучше использовать встроенные в Mongo генераторы которые обеспечат правильный уникальный ключ.

Если конечно мы не делаем базу для обратного nslookup.


А где здесь ObjectId? Просто строку вставили в качестве _id. Никакого ObjectId здесь нет и в помине.

Вы - специалист в MongoDb?
26 май 19, 16:06    [21894155]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Тут мне вспоминается текст из Бородино:

> Земля тряслась — как наши груди,
> Смешались в кучу кони, люди,

Это же надо было так все в кучу намешать.


mayton
Типизацию я поддерживаю. Как способ strong check данных на входе и на выходе. Но из личного опыта использования
баз данных я остаюсь убежден в том что строковый формат представления информации на сегодняшний день является
наиболее удобным и универсальным.

Надеюсь числа не храните в строках? А то напридумывали всяких форматов с плавающей точкой, проще в строке сохранить, а потом на яве сразу передать эту строку в конструктор BigDecimal, да?


mayton
Если-бы было наоборот - то в монго мы бы вставляли просто Java-serialized объекты в Externalized или Serialized формате как key-value db.

Да вставляйте, кто не дает то. Если вы не видите причин чтобы так не делать, то делайте.

mayton
Но это не происходит. На практике мы всё равно используем BSON-дерево из различных типов большая часть
всё равно строковые (именно в силу природы вещей, или в силу входных данных). Более того. Все новые. Неизвестные
и неидентифицированные входные данные 99% будут строками. Такой-вот либерализм этой модели.

Что у вас там за неидентифицированные данные?


mayton
Строгая типизация всего документа скорее всего противоречила-бы самой идее Mongo-документа или навязывала-бы нам
другое техническое задание где был-бы не Mongo-двигатель а какой-нибудь RDBMS.

Строгая типизация это что такое?
Вообще в монге есть валидация схемы, но вы про не знали конечно https://docs.mongodb.com/manual/core/schema-validation/
По вашему, получается, монга противоречива самой себе? Да и не пойму я полета вашей мысли, у вас одно и то же поле в пределах коллекции может от документа к документу типы менять?

mayton
Либеральный тип sting даст нам возможность залоггировать IPv4, IPv6, domain-name и более широкий спектр значений.
А проверки на домен значений мы можем сделать на клиенте.

Да это понятно, что можно. Тут вопрос не в том, что можно, а в том как лучше.
При поиске по коллекции тоже будете ее на клиенте перебирать?

mayton
Мы живём в эпоху BigData и носителей информации которые стоят меньше цента за мегабайт. И разумно думать скорее
об удобстве программирования и использования. Никто вас не похвалит за экономию 96 (128 - 32 = 96bit) бит информации
за каждый документ. (Да я еще раз делаю упор именно на документ. А документ это порция информации заведомо больше
чем data-row для key-value. Я вангую что документ обычно начинаетяс от 1 килобайта информации)
А вот проблемы при отчотах (два поля для IPv4, IPv6) или кастинг на map-reduce операциях

Вы вроде в разделе Java завсегдатый, а что такое биг-дейта не знаете? Зачем ее сюда приплетать, какое отношение она имеет к вопросу о способе хранения данных в монге? Или вы хедупом будете потом записанный ранее " IPv4, IPv6, domain-name и более широкий спектр значений" искать по коллекции с непонятными полями?
Более того, тут в топике уже не раз написали о том, что проблема не столько в дисковом пространстве, сколько в ОЗУ, в которой индекс загружен. И экономию в битах измерять, это весьма странно? А индекс посчитали? А если их несколько? Откуда информация про 1 килобайтный размер документа вообще?

mayton
IPv6 (кстати) при грамотном распределении блоков позволит кстати экономить место на нулях в нотации записи адреса.


Вот рандомный IPv6 адрес 2a02:810c:1bf:b204:f142:ca18:6b06:484b
Чтобы не быть голословным, продемонстрируйте пожалуйста, как вы грамотно блоки распределите для экономии?
26 май 19, 16:23    [21894163]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Hett
пропущено...


А где здесь ObjectId? Просто строку вставили в качестве _id. Никакого ObjectId здесь нет и в помине.

Вы - специалист в MongoDb?


Что подразумевается под "специалист"? Больше 5 лет я с ней работаю. Вы так на вопрос то и не ответили, где ObjectId? Не съезжате с темы, уважаемый.
26 май 19, 16:25    [21894166]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
пропущено...

Вы - специалист в MongoDb?


Что подразумевается под "специалист"? Больше 5 лет я с ней работаю. Вы так на вопрос то и не ответили, где ObjectId? Не съезжате с темы, уважаемый.

Отлично. Я ждал этого. Тогда почему был использован
{_id:"fe80::f42:c2c3:d57:ce60"} 

?
вместо
{ipv6:"fe80::f42:c2c3:d57:ce60"}

Это - дизайн будущей БД. И любое действие надо обосновывать.
26 май 19, 19:11    [21894224]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
vikkiv
Member

Откуда: London
Сообщений: 2399
mayton
... Тогда почему был использован ... И любое действие надо обосновывать...
для экономии места и количиства тырканий по клавишам,
человек сказал что не имел дела - ему дали возможность
сделать это без особых затрат (если появится такое желание),
только и всего, всё остальное - домыслы.
26 май 19, 19:23    [21894227]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Hett
пропущено...


Что подразумевается под "специалист"? Больше 5 лет я с ней работаю. Вы так на вопрос то и не ответили, где ObjectId? Не съезжате с темы, уважаемый.

Отлично. Я ждал этого. Тогда почему был использован
{_id:"fe80::f42:c2c3:d57:ce60"} 

?
вместо
{ipv6:"fe80::f42:c2c3:d57:ce60"}

Это - дизайн будущей БД. И любое действие надо обосновывать.


Я то откуда знаю) Это не мой дизайн. Я лишь поправил по поводу того, что там нет ObjectId.

Кстати адреса v4 и v6 хранят в одном поле, поэтому поле будет скорее называться просто ip
26 май 19, 19:28    [21894228]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton,

и заметьте, я в отличие от вас вопросы не игорирую и отвечаю за свои... гм, посты!
26 май 19, 19:30    [21894229]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Я выше писал 21894120 что рассматриваю документы которые мы кладем в MongoDb именно как документы.
Со всеми вытекающими. Размер в 1 килобайт я взял с потолка. Считайте что это просто экспертная точка зрения.
Но если у вас есть ваш размер - прошу. Озвучьте. Или посчитайте какой средний размер имеют ваши документы
в вашей БД. Почему я апелирую к цифрам? Так иногда проще проводить сравнения и решать где мы чего
по настоящему экономим. А где так. Просто захотели переусложнить.

И зачем вы объявили атрибут ip первичным ключом для документа? Мы можете дать словесное описание
этому дизайну? Для - это важно. Это определяет смыслы.

Ведь вам самый первый вопрос касался смыслов. Какие значение давать константам.
26 май 19, 19:37    [21894230]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
Тут мне вспоминается текст из Бородино:

> Земля тряслась — как наши груди,
> Смешались в кучу кони, люди,

Это же надо было так все в кучу намешать.

Рад что эта куча заставила вас взволноваться. Прошу прощения.
Просто это моя манера выходить на дискурс.

Так ведь без дискурса вы бы и толкали адреса в бинарных блобах. А после общения
со мной ... может у вас и другая мысль засядет. Семя сомнения.
26 май 19, 19:39    [21894232]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
Строгая типизация это что такое?
Вообще в монге есть валидация схемы, но вы про не знали конечно https://docs.mongodb.com/manual/core/schema-validation/
По вашему, получается, монга противоречива самой себе? Да и не пойму я полета вашей мысли, у вас одно и то же поле в пределах коллекции может от документа к документу типы менять?

И как часто вы или ваши коллеги используют эту "валидацию" схемы? Ну.. в % соотношени. Например 50% использую - это
на каждые 2 базы - только одна схема.
26 май 19, 19:41    [21894233]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
И зачем вы объявили атрибут ip первичным ключом для документа? Мы можете дать словесное описание
этому дизайну? Для - это важно. Это определяет смыслы.

Да где я что объявил то? :)

mayton
Или посчитайте какой средний размер имеют ваши документы
в вашей БД.

Какой смысл? Есть, например коллекция auth_log


"size" : 4294967125.0,
"count" : 15368219.0,
"avgObjSize" : 279.0,
....
"nindexes" : 8.0,
"totalIndexSize" : 2638647296.0,

Почти во всех индексах учествует поле ip (бинарное, где хранятся ipv4 и v6 адреса). Будь оно текстовое, все это добро куда больше бы весило, особенно индексы.
26 май 19, 19:48    [21894235]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
И как часто вы или ваши коллеги используют эту "валидацию" схемы? Ну.. в % соотношени. Например 50% использую - это
на каждые 2 базы - только одна схема.


Так я про распространенность ничего не говорю, считать смысла не вижу, базы достаточно разные, на новых микросервисах используем, на старых нет. Причем тут частота, я лишь сказал, что это есть, где вы говорили что это противоречит документным DBMS
26 май 19, 19:50    [21894236]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton, что на счет этого?

Hett
Вот рандомный IPv6 адрес 2a02:810c:1bf:b204:f142:ca18:6b06:484b
Чтобы не быть голословным, продемонстрируйте пожалуйста, как вы грамотно блоки распределите для экономии?
26 май 19, 19:52    [21894238]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
И как часто вы или ваши коллеги используют эту "валидацию" схемы? Ну.. в % соотношени. Например 50% использую - это
на каждые 2 базы - только одна схема.


Так я про распространенность ничего не говорю, считать смысла не вижу, базы достаточно разные, на новых микросервисах используем, на старых нет. Причем тут частота, я лишь сказал, что это есть, где вы говорили что это противоречит документным DBMS

Кайл Бэнкер в MongoDb in Action пишет что Отсутствие предопределённой
схемы несет с собой некоторые преимущества
.
Далее - он разворачивает мысль. Там целый абзац. Почитайте.

По поводу распространения. Некое подобие схемы валидатора было заложена в Oracle 10g еще лет 10 назад.
Позволяло для полей типа XmlType проверять валидность документа. Но % использования этой фичи
близок к нулю. В таких случаях наука говорит - практически не используется.
26 май 19, 20:06    [21894241]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton, что на счет этого?

Hett
Вот рандомный IPv6 адрес 2a02:810c:1bf:b204:f142:ca18:6b06:484b
Чтобы не быть голословным, продемонстрируйте пожалуйста, как вы грамотно блоки распределите для экономии?

Я говорю о правильном распределении адресов. А не о том рандомном шуме что вам присвоил ваш провайдер.
26 май 19, 20:07    [21894242]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Hett
mayton, что на счет этого?

пропущено...

Я говорю о правильном распределении адресов. А не о том рандомном шуме что вам присвоил ваш провайдер.


Ясно :)
26 май 19, 20:14    [21894244]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
автор
Кайл Бэнкер

Кто это?
26 май 19, 20:22    [21894246]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Kyle Banker

https://www.amazon.com/MongoDB-Action-Covers-version-3-0/dp/1617291609
26 май 19, 20:26    [21894248]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett

"size" : 4294967125.0,
"count" : 15368219.0,
"avgObjSize" : 279.0,
....
"nindexes" : 8.0,
"totalIndexSize" : 2638647296.0,
Почти во всех индексах учествует поле ip (бинарное, где хранятся ipv4 и v6 адреса). Будь оно текстовое, все это добро куда больше бы весило, особенно индексы.

Метафорами - "куда больше" требует уточнения.
Вы можете сейчас создать новый текстовое поле ip, перелить туда данные и перестроить все индексы?

Я хочу - цифры. Я привык оперировать цифрами.
26 май 19, 20:29    [21894250]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
Если будет скучно, посмотрю на досуге. Особого смысла все равно не вижу в этом, тем более там бинарный поиск используется.
26 май 19, 20:42    [21894253]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Посмотрите. Всенепременно.
26 май 19, 20:43    [21894254]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
miksoft
Member

Откуда:
Сообщений: 37672
mayton
Никто вас не похвалит за экономию 96 (128 - 32 = 96bit) бит информации за каждый документ.
У нас похвалят. Правда, максимум, коллеги по команде. Но тем не менее.
У нас жесткий лимит на размер базы, в который мы скоро упремся. И нам не дадут увеличить его, пока не будет убедительно показано, что сжимать дальше уже некуда.
26 май 19, 22:22    [21894289]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
miksoft,

Что за база такая? Какой-нибудь embeded?
26 май 19, 22:34    [21894293]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
fkthat
Member

Откуда:
Сообщений: 1163
Hett,

ObjectId в монге опционален - требуется лишь уникальное поле "_id", его тип может быть любой. Говорят, что вроде бы монговский ObjectId как-то оптимизирован под шардинг, но это лучше у более специалистов чем я спрашивать.
26 май 19, 22:38    [21894296]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
miksoft
Member

Откуда:
Сообщений: 37672
fkthat
miksoft,

Что за база такая? Какой-нибудь embeded?
Наоборот, аналитическое хранилище.
26 май 19, 22:40    [21894298]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Наверное column-oriented storage. Для них разрядность данного конкретного поля важнее.
26 май 19, 23:33    [21894320]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 16237
Hett
Так я делал всегда и думал, что это правильно. Но недавно в команде появился человек, которого очень смутило то, что константы числовые и анализировать базу данных ему не удобно (он не аналитик, он программист), типа с текстовыми было бы проще.
он казёл, которого надо гнать.
потому что программист такое сказать не может.
вот слова программиста
Hett
Лично я считаю, что база данных в первую очередь для приложения, а не человека и должна быть оптимизирована под работу приложения.
27 май 19, 07:06    [21894364]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
fkthat
Hett,

ObjectId в монге опционален - требуется лишь уникальное поле "_id", его тип может быть любой. Говорят, что вроде бы монговский ObjectId как-то оптимизирован под шардинг, но это лучше у более специалистов чем я спрашивать.

Вы это мейтону наверное хотели адресовать?
27 май 19, 08:35    [21894400]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.
27 май 19, 09:24    [21894421]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.


А чем буквы лучше? Если первый раз видишь базу, то они все равно ничем не помогут.
А если не первый, то скорее запутаешься рано или поздно из-за лени лишний раз проверить что какая буква означает.
Может оно выглядит читаемо пока коллекция одна, а когда их много и статусы похожи друг на друга - упомнить все будет сложно.

Если два состояния будут с одной буквы начинаться, нужно будет двух-буквенный код вводить. При этом изначально коллизии может и не быть, а добавится потом. Что делать?
27 май 19, 09:29    [21894424]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
В таком случе уж лучше использовать полные названия. На размер индекса это сильно не должно повлиять. На скорость поиска - сложно сказать.
27 май 19, 09:31    [21894426]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Из личного опыта. Одной-двух букв тебе хватит надолго. На справочник до 1000 примерно.

Вспомни коды стран и валют https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes
27 май 19, 09:32    [21894428]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
https://en.wikipedia.org/wiki/ISO_4217
27 май 19, 09:35    [21894429]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 16237
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.
если это на всегда - то вопрос решается путём сравнения скорости обработки, если же это только начальный вариант - то цифры лучше - проще вкладывать новый смысл в цифру, не надо остальную логику передумывать.
на и с цифрами индексация быстрее
27 май 19, 09:35    [21894431]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
вадя
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.
если это на всегда - то вопрос решается путём сравнения скорости обработки, если же это только начальный вариант - то цифры лучше - проще вкладывать новый смысл в цифру, не надо остальную логику передумывать.
на и с цифрами индексация быстрее

Почему быстрее?
27 май 19, 09:35    [21894433]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 16237
mayton
Почему быстрее?
потому как числовое поле рассматривается как одно целое значение, а чаровское как набор отдельных значений.
27 май 19, 09:48    [21894439]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Мы говорим про Mongo?
27 май 19, 09:49    [21894443]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 16237
mayton
Мы говорим про Mongo?
неужели Mongo выбрало тормозной путь?
27 май 19, 09:50    [21894446]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Изопропил
Member

Откуда:
Сообщений: 31189
Hett
анализировать базу данных ему не удобно (он не аналитик, он программист)

пущай вьюер запргограммирует
27 май 19, 09:53    [21894449]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Dima T
Member

Откуда:
Сообщений: 13915
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.

ИМХО все зависит от того как оно в базу пишется, точнее сколько места занимает. Т.к. в итоге все упрется в I/O, и на скорость выборки основное влияние окажет размер.
27 май 19, 10:18    [21894470]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
вадя
mayton
Мы говорим про Mongo?
неужели Mongo выбрало тормозной путь?

Я не знаю. Не забывай что Mongo хранит не строки данных как в таблице а документы.

По бенчмарку. Безотносительно быстрых или медленных компараторов надо понимать что бенчмарк
должен быть не синтетический. А приближенный к реальным условиям. Тоесть базёнка из двух полей
которая улеглась - в оперативе - это не наш кейс. Потому-что - синтетический. Нужен - настоящий.
27 май 19, 10:19    [21894471]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Dima T
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.

ИМХО все зависит от того как оно в базу пишется, точнее сколько места занимает. Т.к. в итоге все упрется в I/O, и на скорость выборки основное влияние окажет размер.

Не знаю. Пишут что пухлое тело Mongo-базы лежит в формате BSON.
Вроде-бы он поддерживает бинарные числовые типы.

http://bsonspec.org/spec.html

Точно ли оно сохранит наши ключи - это тот еще вопрос. Я-бы после создания документа делал-бы дамп или экспорт и смотрел.
27 май 19, 10:25    [21894477]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
автор
Точно ли оно сохранит наши ключи

Какие ключи?
27 май 19, 11:24    [21894527]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58418
Блог
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.

Я сказал. 10, 20 и 30 не бывают прописными и строчными.
27 май 19, 12:03    [21894601]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
автор
Точно ли оно сохранит наши ключи

Какие ключи?

А вы сударь изволили обещать сравнить текстовое и двоичное хранение адресов с индексами
и накладными расходами.

А ключи - это то с чего начался топик.
27 май 19, 12:04    [21894604]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
alex55555
Member

Откуда:
Сообщений: 2129
mayton
В топике никто так и не высказался почему 10,20,30 должны быть лучше чем 'a','u','r'.

Буквы хуже. Вместо букв тогда надо слова, а лучше фразы.

Собственно спич об оптимизации. Пока всего полно и ничего не жалко - можно хоть мегабайтный вордовский документ в качестве ключа использовать. Будет там и описание названий и зачем и почему и ещё сказка на ночь. Но когда возникает потребность в эффективности - вот тут все вордовские документы, и строки, и буквы - идут лесом.
27 май 19, 12:11    [21894612]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Hett
пропущено...

Какие ключи?

А вы сударь изволили обещать сравнить текстовое и двоичное хранение адресов с индексами
и накладными расходами.

А ключи - это то с чего начался топик.


Обещать? Может я еще клятву дал? :)

Hett
Если будет скучно, посмотрю на досуге. Особого смысла все равно не вижу в этом, тем более там бинарный поиск используется.
27 май 19, 12:16    [21894622]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
Hett
Member

Откуда: Бийск, Новосибирск
Сообщений: 13556
mayton
Не знаю. Пишут что пухлое тело Mongo-базы лежит в формате BSON.
Вроде-бы он поддерживает бинарные числовые типы.

http://bsonspec.org/spec.html



На счет пухлости, я бы не был так категоричен. В WireTiger довольно не плохое сжатие.

mayton
Точно ли оно сохранит наши ключи - это тот еще вопрос. Я-бы после создания документа делал-бы дамп или экспорт и смотрел.


Как понять "точно ли оно сохранит"?
Что вы хотите в дампе то увидеть?
27 май 19, 12:21    [21894633]     Ответить | Цитировать Сообщить модератору
 Re: String constants vs int  [new]
mayton
Member

Откуда: loopback
Сообщений: 41808
Hett
mayton
Не знаю. Пишут что пухлое тело Mongo-базы лежит в формате BSON.
Вроде-бы он поддерживает бинарные числовые типы.

http://bsonspec.org/spec.html



На счет пухлости, я бы не был так категоричен. В WireTiger довольно не плохое сжатие.

mayton
Точно ли оно сохранит наши ключи - это тот еще вопрос. Я-бы после создания документа делал-бы дамп или экспорт и смотрел.


Как понять "точно ли оно сохранит"?
Что вы хотите в дампе то увидеть?

А вы - ревностный адепт. Это приятно.

Пока не знаю что хочу увидеть. Целей много.
27 май 19, 13:29    [21894756]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4      [все]
Все форумы / Программирование Ответить