Есть ли набор предпочтительных соглашений об именах для мандатов MongoDB, таких как базы данных, коллекции, имена полей?
Я думал об этом:
Keep'em short: Оптимизация хранения небольших объектов, SERVER-863. Глупо, но верно.
Я предполагаю, что те же правила, которые применяются к базам данных отношений, должны применяться здесь. И после стольких десятилетий до сих пор нет соглашения о том, должны ли таблицы РСУБД быть названы единичными или множественными...
MongoDB говорит на JavaScript, поэтому используйте соглашения об именах JS.
Официальная документация MongoDB, по-видимому, предпочитает подчеркивание, также встроенный идентификатор имеет имя _id...
Даже если об этом не указано никакое соглашение, справочные ссылки последовательно называются после ссылочной коллекции в документации Mongo, одно отношение. Имя всегда следует структуре <document>_id.
Например, в коллекции dogs документ будет иметь ссылки на внешние документы, названные так:
{
name: 'fido',
owner_id: '5358e4249611f4a65e3068ab',
race_id: '5358ee549611f4a65e3068ac',
colour: 'yellow'
...
}
Это следует за Монгольским соглашением о присвоении имени _id идентификатора для каждого документа.
Соглашение об именах для коллекции
Чтобы назвать коллекцию, необходимо принять несколько мер предосторожности:
Было бы неплохо не содержать символ "$" в имени коллекции, поскольку различные драйверы, доступные для базы данных, не поддерживают "$" в имени коллекции.
При создании имени базы данных следует иметь в виду:
Для получения дополнительной информации. Пожалуйста, проверьте приведенную ниже ссылку: http://www.learnit.net.in/2016/03/schema-design-and-naming-conventions-in.html
До тех пор, пока мы не получим SERVER-863, если желательно, чтобы имена полей были как можно более короткими особенно там, где у вас много записей.
В зависимости от вашего варианта использования имена полей могут иметь огромное влияние на хранилище. Не могу понять, почему это не более высокий приоритет для MongoDb, так как это окажет положительное влияние на всех пользователей. Если ничего другого, мы можем начать более описательно с именами наших полей, не думая дважды о пропускной способности и стоимости хранения.
Просьба голосовать.
Я думаю, это все личные предпочтения. Мои предпочтения исходят от использования NHibernate в .NET с SQL Server, поэтому они, вероятно, отличаются от других.
Честно говоря, это не имеет большого значения, если это согласуется с проектом. Просто приступайте к работе и не потейте детали: P
DATABASE
MongoDB указывает хороший пример:
Чтобы выбрать базу данных для использования, в оболочке mongo, используйте, как в следующем примере:
использовать myDB
использовать myNewDB
Содержимое из: https://docs.mongodb.com/manual/core/databases-and-collections/#databases
КОЛЛЕКЦИИ
Имена нижнего регистра: устраняет проблемы чувствительности к регистру, имена коллекции MongoDB чувствительны к регистру.
Множественное: более очевидное обозначение коллекции чего-то как множественного числа, например. "файлы", а не "файл"
Нет разделителей слов: Избегает проблем, когда разные люди (некорректно) разделяют слова (имя пользователя ↔ имя_пользователя, first_name ↔
имя). Этот вопрос обсуждается в соответствии с несколькими людьми
здесь, но при условии, что аргумент изолирован от имен коллекции Я не думаю, что это должно быть;) Если вы обнаружите, что улучшаете читаемость имени вашей коллекции путем добавления подчеркивания или camelCasing имя вашей коллекции, вероятно, слишком длинное или должно использовать периоды по мере необходимости, что является стандартом для сбора информации категоризации.Точечная нотация для более подробных коллекций: Дает указание на то, как связаны коллекции. Например, вы можете разумно уверен, что вы можете удалить "users.pagevisits", если вы удалили "пользователи", если люди, которые разработали схему, сделали хороший работа.
Содержимое от: http://www.learnit.net.in/2016/03/schema-design-and-naming-conventions-in.html
Для коллекций я следую этим предложенным шаблонам, пока не найду официальную документацию MongoDB.