Каковы соглашения об именах для MongoDB?


188

Существует ли набор предпочтительных соглашений об именах для прав MongoDB, таких как базы данных, коллекции, имена полей?

Я думал так:

  • Базы данных: состоят из цели (слово в единственном числе) и заканчиваются на «db» - все строчные буквы: imagedb, resumedb, memberdb и т. Д.
  • Коллекции: множественное число в нижнем регистре: изображения, резюме,
  • Поля документа: lowerCamelCase, например, memberFirstName, fileName и т. Д.

Ответы:


128
  1. Keep'em short: Оптимизация хранения мелких объектов , SERVER-863 . Глупо, но правда.

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

  3. MongoDB говорит на JavaScript, поэтому используйте соглашения по именованию JS camelCase.

  4. В официальной документации MongoDB упоминается, что вы можете использовать подчеркивания, также именуется встроенный идентификатор _id(но это может означать, что _idон предназначен для частного, внутреннего, никогда не показывается и не редактируется).


95
3 и 4 противоречивы - JS предпочитает верблюд, Монго, кажется, предпочитает подчеркивание ... но, если сомневаетесь, используйте подчеркивание. Люди, привыкшие к нелатинским алфавитам, будут вам благодарны.
Мэтт Жуковски

1
См. Этот вопрос для дебатов единственного против множественного числа: stackoverflow.com/questions/338156/…
Джейсон

4
Я не уверен, что скажу "JS предпочитает верблюд". Сам JS не имеет предпочтений, но, возможно, верно сказать, что большинство программистов JS склонны использовать верблюжий случай.
Treeface

1
@treeface Я думаю, Мэтт имел в виду тот факт, что все встроенные методы JS используют camelCase, как в узлах, так и в браузерах
Люк Тейлор

1
Встроенный идентификатор _id, скорее всего, имеет префикс с подчеркиванием, чтобы следовать общепринятому соглашению JavaScript, которое указывает, что ключ должен быть внутренним / закрытым ключом. Другими словами, _idон не предназначен для того, чтобы когда-либо редактировать его или представлять кому-либо, просматривающему данные коллекции.
Бо Смит

58

БАЗА ДАННЫХ

  • верблюжьего
  • добавить БД в конец имени
  • сделать единственное число (коллекции во множественном числе)

MongoDB приводит хороший пример:

Чтобы выбрать базу данных для использования, в оболочке mongo введите оператор use <db>, как в следующем примере:

использовать myDB
использовать myNewDB

Содержание из: https://docs.mongodb.com/manual/core/databases-and-collections/#databases

КОЛЛЕКЦИИ

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

  • Множественное: более очевидно обозначать коллекцию чего-либо как множественное число, например, «файлы», а не «файл»

  • > Нет разделителей слов: позволяет избежать проблем, когда разные люди (неправильно) разделяют слова (имя пользователя <-> имя_пользователя, имя_первой <-> имя
    ). Этот
    вопрос подлежит обсуждению в соответствии с несколькими людьми, присутствующими здесь, но при условии, что аргумент изолирован от названий коллекций, я не думаю, что это должно быть;) Если вы обнаружите, что улучшаете
    читабельность названия своей коллекции, добавив подчеркивание или
    верблюжий знак своей коллекции имя, вероятно, слишком длинное или должно использовать
    периоды в зависимости от обстоятельств, что является стандартом для
    классификации коллекции .

  • Точечная запись для более подробных коллекций: дает некоторое представление о том, как коллекции связаны. Например, вы можете быть уверены, что можете удалить «users.pagevisits», если удалили «users», при условии, что люди, разработавшие схему, справились с работой.

Содержание от: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Для коллекций я следую этим предложенным шаблонам, пока не найду официальную документацию MongoDB.


25

Даже если об этом не указано никакого соглашения, ссылки для руководства последовательно называются в соответствии со ссылочной коллекцией в документации Mongo для отношений один-к-одному. Имя всегда следует за структурой <document>_id.

Например, в dogsколлекции документ будет иметь ручные ссылки на внешние документы, названные так:

{
  name: 'fido',
  owner_id: '5358e4249611f4a65e3068ab',
  race_id: '5358ee549611f4a65e3068ac',
  colour: 'yellow'
  ...
}

Это следует соглашению Монго о присвоении _idимени идентификатору для каждого документа.


1
я не упомянул camelCase в своем ответе, поэтому я бы использовалowner_id
danza

8

Соглашение об именовании для коллекции

Чтобы назвать коллекцию, нужно принять несколько мер предосторожности:

  1. Коллекция с пустой строкой («») не является допустимым именем коллекции.
  2. Имя коллекции не должно содержать нулевой символ, поскольку оно определяет конец имени коллекции.
  3. Название коллекции не должно начинаться с префикса «system». так как это зарезервировано для внутренних коллекций.
  4. Было бы хорошо не указывать символ «$» в имени коллекции, поскольку различные драйверы, доступные для базы данных, не поддерживают «$» в имени коллекции.

    При создании имени базы данных необходимо учитывать следующее:

  5. База данных с пустой строкой («») не является допустимым именем базы данных.
  6. Имя базы данных не может превышать 64 байта.
  7. Имя базы данных чувствительно к регистру, даже в не чувствительных к регистру файловых системах. Таким образом, хорошо держать имя в нижнем регистре.
  8. Имя базы данных не может содержать ни одного из этих символов «/, \,.,«, *, <,>,:, |,?, $, ». Он также не может содержать ни одного пробела или нулевого символа.

Чтобы получить больше информации. Пожалуйста, проверьте ссылку ниже: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html


3

Я думаю, что это все личные предпочтения. Мои предпочтения связаны с использованием NHibernate в .NET с SQL Server, поэтому они, вероятно, отличаются от того, что используют другие.

  • Базы данных: приложение, которое используется .. например: Stackoverflow
  • Коллекции: Единственное в названии, что это будет за коллекция, например: Вопрос
  • Поля документа, например: MemberFirstName

Честно говоря, это не имеет большого значения, если оно соответствует проекту. Просто приступай к работе и не парься в деталях: P


1
Я думаю, что последствия могут иметь поля документа, поскольку они будут храниться внутри каждого документа. Как отметил Томаш, их сокращение должно сэкономить пространство / пропускную способность. Я думаю, что гораздо важнее, чтобы вы использовали то, что облегчает понимание.
Рекс Морган

2

Пока мы не получим SERVER-863, желательно, чтобы имена полей были как можно короче, особенно если у вас много записей.

В зависимости от вашего варианта использования имена полей могут иметь огромное влияние на хранилище. Не могу понять, почему это не является более высоким приоритетом для MongoDb, так как это окажет положительное влияние на всех пользователей. Если не сказать больше, мы можем начать описывать имена наших полей, не задумываясь о пропускной способности и стоимости хранения.

Пожалуйста, проголосуйте .


Для того, чтобы обновить потенциальных читателей этого ответа в будущем, MongoDB в наши дни выполняет сжатие, поэтому длинные имена полей больше не являются проблемой.
Hubro
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.