Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Программирование Ответить