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

Question

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

Я думал так:

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

Answer 1

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

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

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

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

Answer 2

DATABASE

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

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

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

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

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

КОЛЛЕКЦИЯ

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

   Что нужно сохранитьпри создании имени базы данных имейте в виду:

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

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

Answer 5

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

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

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

Answer 6

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

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

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