Сохранить перечисление MongoDB

Я храню перечисления для таких вещей, как ранги (администратор, модератор, пользователь...) и достижения для каждого пользователя в моей базе данных Mongo. Насколько я знаю, у Mongo нет типа данных перечисления, что означает, что я должен хранить его с помощью другого типа.

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

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

ОТВЕТЫ

Ответ 1

TL; DR: Строки, вероятно, являются более безопасным выбором, и разница в производительности должна быть незначительной. Целые имеют смысл для огромных коллекций, где перечисление должно быть проиндексировано. YMMV.

Я думал о его хранении с использованием целых чисел, которые, как я полагаю, использует меньше места, чем хранение строк для всего, что может быть легко выражено как целое число

True.

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

Это ключевое преимущество целых чисел, на мой взгляд. Однако для этого также требуется убедиться, что связанные значения enum не изменяются. Если вы ввернете это, вы будете почти наверняка иметь havoc, что является огромным недостатком.

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

Если вы действительно используете тип данных enum, он, вероятно, имеет какое-то целое число внутри, поэтому целое число должно требовать меньше обработки. В любом случае, накладные расходы должны быть незначительными.

Есть ли веская причина использовать целые числа или строки?

Я повторяю много сказанного, но, возможно, это помогает другим читателям. Подведение итогов:

  • Смешение карты значений enum приводит к хаосу. Представьте, что ваши состояния Declined неожиданно интерпретируются как Accepted, потому что Declined имеет значение "2", а теперь оно Accepted, потому что вы переупорядочиваете перечисление и забываете назначать значения вручную... (дрожи)
  • Строки более выразительны
  • Целые числа занимают меньше места. Дисковое пространство не имеет значения, как правило, но пространство индекса будет потреблять ОЗУ, что дорого.
  • Целочисленные обновления не изменяют размер объекта. Строки, если их длина сильно различается, может потребовать перераспределения. Тем не менее, добавление строки и коэффициента заполнения должно облегчить это.
  • Целые числа могут быть флагами (еще не запрошенными (пока), к сожалению, см. SERVER-3518)
  • Целые числа могут быть запрошены с помощью $gt/$lt, чтобы вы могли эффективно реализовывать сложные запросы $or, хотя это довольно загадочное требование, и нет ничего плохого в запросах $or...