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

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

Я думал так:

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

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

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

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

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

БАЗА ДАННЫХ

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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