Есть ли смысл в инкрементируемых ИД для всех таблиц в mongodb?

Question

[magary4]

к примеру есть таблица orders. по умолчанию в поле id записывается типа XBFFPcy5K7miHQ3gB. как человек который много лет работал с mysql, хочется завести таблицу couters и писать человеко-понятные ид. нужноли это делать

Answer 1

[Сергей]

С точки зрения машины нет.
ваш ID в MySQL должен быть уникальным, но он не обязан быть последовательно-упорядоченным.
В MongoDB также. Насколько я понимаю, это некий ХЕШ. Который также в первом приближении уникальный.
Вы можете всегда сослаться на эту запись по этому ХЕШу.

Answer 2

[Константин Китманов]

Иногда хочется сходу понимать, какая запись добавлена позже, какая раньше. Но, скорее всего, у вас и так будут поля типа creationDate, updateDate.

Числа нужны для двух вещей: сортировка и арифметические действия. Арифметические действия с айдишниками делать глупо, а сортировать монго будет сама.

Answer 3

[bromzh]

А к чему эти человекопонятные ид? Оставь всё как есть, но создай индекс на поле, в индексе укажи, что он будет уникальный. Поле можешь сделать числовым, или строковым (slug). Автоинкременты придётся самому реализовывать. Поэтому лучше использовать то, что есть. Или перейти на postgresql. В новой версии появился тип json, там последовательности есть, и индексы для офигенно быстрого поиска. Не зря же именно разраб постгреса запилил новый движок для монги, который стал намного быстрее старого.

Answer 4

[lega]

Есть ли смысл в инкрементируемых ИД для всех таблиц в mongodb?

Обычно нет.
У стандартного _id (ObjectID) есть преимущество, он создается до записи в БД, т.е. что-б узнать итоговый ид, не нужно ждать когда запись в БД завершится, в отличие от инкрементального ид.
Это позволяет, например, отдавать клиенту результат сразу, без ожидания записи (когда нужно отдать ид). Или "клиент" может сам задать _id в запросе, и не ждать ответа, зная какой _id будет у документа. Это дает дополнительную гибкость и производительность.