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


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

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

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

Что думаете?

KreatorXXIHett,

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

Количество данных в любом случае больше. Можно использовать 32-битный интерджер (4 байта), с другой стороны получается 8 символов, даже точно не уверен, сколько это займет памяти. Думаю как минимум байт 12 (4 под длину, + 2 байта на каждый символ?).
Как это будет в индексах выглядеть тоже большой вопрос. Особенно если поле участвует в нескольких составных индексах.

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

Программист жеж, знает где найти константы.

Поди еще айпи адреса текстом храните?

fkthatHett,

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

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

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

ps^ Я не говорю про поиск в подсетях, тут то даже спорить было бы не о чем. Допустим это нам точно не понадобится.

fkthatHett,

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

Это IP - это не фрагмент текста и хранится в отдельном поле, то почему бы не хранить его в бинарном виде?

miksoftfkthat"в четыре раза больше", конечно.у кого как, некоторые хранят guid-ы в VARCHAR(36) в виде строки '22345200-abe8-4f60-90c8-0d43c5f6c0f6'.

Эти некоторые уже выше отписались. Если IP хранят в виде строки, то GUID/UUID аналогично, подозреваю.

Это я к тому, что если уж говорить про эти ваши GUID/UUID, то опять же в том контексте, как его хранить, бинарно (с обертками субд) или строкой. А сравнивать его с Int смысла нет, думаю это очевидно.

maytonДля Mongo нет выделенного типа данных Ipv4, Ipv6.

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

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

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

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


PHP





Java

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

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

Когда-то я даже задавался такими вопросами
https://stackoverflow.com/questions/28537599/get-mongobindata-value-from-mongo-shell

softwarer 0::0::1.
Сокращение в адресе может быть только одно.

maytonvikkivпропущено...
https://www.jdoodle.com/online-mongodb-terminal
если есть интерес то для string варианта скопируй туда

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

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

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

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 килобайтный размер документа вообще?

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


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

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


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

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