Що таке правила іменування для MongoDB?

Чи існує набір переважних конвенцій іменування прав MongoDB, таких як бази даних, колекції, назви полів?

Я думав так:

• Бази даних: складаються з мети (слово в однині) і закінчуються на "db" - всі малі регістри: imagedb, resumedb, memberdb тощо.
• Колекції: множина у малому регістрі: зображення, резюме,
• Поля документа: нижчийCamelCase, наприклад, memberFirstName, fileName тощо

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

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

3. MongoDB розмовляє з JavaScript, тому використовуйте JS-конвенції іменування camelCase.

4. Офіційна документація MongoDB зазначає, що ви можете використовувати підкреслення, також вбудований ідентифікатор названий _id(але це може означати, що _idвін повинен бути приватним, внутрішнім, ніколи не відображатися чи редагуватися.

БАНКА

• camelCase
• додайте БД на кінець імені
• скласти однину (колекції множини)

MongoDB наводить прекрасний приклад:

Щоб вибрати базу даних, яку слід використовувати в оболонці mongo, видайте оператор use <db>, як у наступному прикладі:

використовувати myDB
використовувати myNewDB

Вміст: https://docs.mongodb.com/manual/core/databases-and-collections/#databases

КОЛЕКЦІЇ

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

• Множина: більш очевидно позначити колекцію чогось як множини, наприклад, "файли", а не "файл"

• > Немає розділювачів слів: уникає проблем, коли різні люди (неправильно) розділяють слова (ім'я користувача <-> ім’я користувача, ім'я <-> ім'я
  ). Цей варіант готується до дебатів на думку кількох людей
  навколо, але за умови, що аргумент ізольований до назв колекції, я не думаю, що це повинно бути;) Якщо ви виявите, що ви покращуєте
  читабельність імені вашої колекції, додаючи підкреслення або
  верблюдаЗакриваючи свою колекцію ім'я, ймовірно, занадто довге або слід використовувати
  періоди відповідно, що є стандартом для
  категоризації колекцій .

• Позначення крапок для колекцій з більш детальними деталями: дає деяку вказівку на те, як пов’язані колекції. Наприклад, ви можете бути впевнені, що можете видалити "users.pagevisits", якщо ви видалили "користувачів" за умови, що люди, які розробили схему, виконали гарну роботу.

Вміст з: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Для колекцій я дотримуюся цих запропонованих зразків, поки не знайду офіційну документацію MongoDB.

Навіть якщо з цього приводу не вказано жодної конвенції, посібники в посібниках послідовно називаються за посиланням на колекцію в документації Монго для відносин один на один. Назва завжди відповідає структурі <document>_id.

Наприклад, у dogsколекції документ міститиме посилання вручну на зовнішні документи, названі так:

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

Це дотримується Конвенції Монго про іменування _idідентифікатора для кожного документа.

Названня конвенції для збору

Для того, щоб назвати колекцію, слід дотримуватися кількох запобіжних заходів:

1. Колекція з порожнім рядком ("") не є дійсною назвою колекції.
2. Ім'я колекції не повинно містити нульового символу, оскільки це визначає кінець назви колекції.
3. Назва колекції не повинна починатися з префіксу "система". оскільки це зарезервовано для внутрішніх колекцій.

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, оскільки це матиме позитивний вплив на всіх користувачів. Якщо нічого іншого, ми можемо почати бути більш описовими з нашими полями, не замислюючись двічі про пропускну здатність та витрати на зберігання.

Будь ласка, голосуйте .