Существует ли набор предпочтительных соглашений об именах для прав MongoDB, таких как базы данных, коллекции, имена полей?
Я думал так:
Ответы:
Keep'em short: Оптимизация хранения мелких объектов , SERVER-863 . Глупо, но правда.
Я полагаю, что здесь должны применяться те же правила, которые применяются к базам данных отношений. И после стольких десятилетий все еще нет согласия, следует ли называть таблицы RDBMS единичными или множественными ...
MongoDB говорит на JavaScript, поэтому используйте соглашения по именованию JS camelCase.
В официальной документации MongoDB упоминается, что вы можете использовать подчеркивания, также именуется встроенный идентификатор _id(но это может означать, что _idон предназначен для частного, внутреннего, никогда не показывается и не редактируется).
_id, скорее всего, имеет префикс с подчеркиванием, чтобы следовать общепринятому соглашению JavaScript, которое указывает, что ключ должен быть внутренним / закрытым ключом. Другими словами, _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имени идентификатору для каждого документа.
owner_id
Соглашение об именовании для коллекции
Чтобы назвать коллекцию, нужно принять несколько мер предосторожности:
Было бы хорошо не указывать символ «$» в имени коллекции, поскольку различные драйверы, доступные для базы данных, не поддерживают «$» в имени коллекции.
При создании имени базы данных необходимо учитывать следующее:
Чтобы получить больше информации. Пожалуйста, проверьте ссылку ниже: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html
Я думаю, что это все личные предпочтения. Мои предпочтения связаны с использованием NHibernate в .NET с SQL Server, поэтому они, вероятно, отличаются от того, что используют другие.
Честно говоря, это не имеет большого значения, если оно соответствует проекту. Просто приступай к работе и не парься в деталях: P
Пока мы не получим SERVER-863, желательно, чтобы имена полей были как можно короче, особенно если у вас много записей.
В зависимости от вашего варианта использования имена полей могут иметь огромное влияние на хранилище. Не могу понять, почему это не является более высоким приоритетом для MongoDb, так как это окажет положительное влияние на всех пользователей. Если не сказать больше, мы можем начать описывать имена наших полей, не задумываясь о пропускной способности и стоимости хранения.
Пожалуйста, проголосуйте .