Jakie są konwencje nazewnictwa dla MongoDB?

Czy istnieje zestaw preferowanych konwencji nazewnictwa dla uprawnień MongoDB, takich jak bazy danych, zbiory, nazwy pól?

Myślałem w następujący sposób:

• Bazy danych: składają się z celu (słowo w liczbie pojedynczej) i kończą się na „db” - wszystkie małe litery: imagedb, resumedb, memberdb itp.
• Kolekcje: liczba mnoga małymi literami: obrazy, CV,
• Pola dokumentu: lowerCamelCase, np. MemberFirstName, fileName itp

1. Krótko mówiąc: optymalizacja przechowywania małych obiektów , SERVER-863 . Głupie, ale prawdziwe.

2. Sądzę, że powinny tu obowiązywać te same zasady, które dotyczą baz danych relacji. Po tylu dekadach wciąż nie ma zgody, czy tabele RDBMS powinny być nazywane pojedynczymi czy mnogimi ...

3. MongoDB mówi JavaScript, więc używaj konwencji nazewnictwa JS camelCase.

4. Oficjalna dokumentacja MongoDB wspomina, że ​​możesz używać podkreślników, nazywa się także wbudowany identyfikator _id(ale może to oznaczać, że _idma być prywatny, wewnętrzny, nigdy nie wyświetlany lub edytowany).

BAZA DANYCH

• camelCase
• dołącz DB na końcu nazwy
• zrób liczbę pojedynczą (zbiory są w liczbie mnogiej)

MongoDB stanowi dobry przykład:

Aby wybrać bazę danych do użycia, w powłoce mangowej wydaj instrukcję use <db>, jak w poniższym przykładzie:

użyj myDB
użyj myNewDB

Treść z: https://docs.mongodb.com/manual/core/databases-and-collections/#databases

KOLEKCJE

• Nazwy małych liter : pozwala uniknąć problemów z rozróżnianiem wielkości liter, w nazwach kolekcji MongoDB rozróżniana jest wielkość liter.

• Liczba mnoga: bardziej oczywiste jest oznaczanie zbioru czegoś jako liczby mnogiej, np. „Pliki” zamiast „plik”

• > Brak separatorów słów: Zapobiega problemom polegającym na tym, że różne osoby (niepoprawnie) oddzielają słowa (nazwa użytkownika <-> nazwa_użytkownika,
  imię <-> imię). Ta dyskusja jest przedmiotem dyskusji dla kilku osób
  tutaj, ale pod warunkiem, że argument jest odizolowany od nazw kolekcji, nie sądzę, że powinna być;) Jeśli polepszysz
  czytelność nazwy swojej kolekcji, dodając podkreślenia lub
  wielbłąda. nazwa jest prawdopodobnie zbyt długa lub powinna zawierać
  odpowiednie kropki, co jest standardem w
  kategoryzacji kolekcji .

• Notacja punktowa dla kolekcji o większej szczegółowości: Daje pewne wskazówki na temat powiązania kolekcji. Na przykład możesz mieć pewność, że możesz usunąć „users.pagevisits”, jeśli usunąłeś „users”, pod warunkiem, że osoby, które zaprojektowały schemat, wykonały dobrą robotę.

Treść z: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

W przypadku kolekcji stosuję się do tych sugerowanych wzorów, dopóki nie znajdę oficjalnej dokumentacji MongoDB.

Nawet jeśli nie określono żadnej konwencji w tym zakresie, ręczne odniesienia są konsekwentnie nazywane na podstawie kolekcji, do której istnieją odniesienia w dokumentacji Mongo, dla relacji jeden-do-jednego. Nazwa zawsze podąża za strukturą <document>_id.

Na przykład w dogskolekcji dokument zawierałby ręczne odniesienia do dokumentów zewnętrznych o nazwie takiej:

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

Jest to zgodne z konwencją Mongo dotyczącą nazywania _ididentyfikatora dla każdego dokumentu.

Konwencja nazewnictwa dla kolekcji

Aby nazwać kolekcję, należy podjąć kilka środków ostrożności:

1. Kolekcja z pustym ciągiem („”) nie jest prawidłową nazwą kolekcji.
2. Nazwa kolekcji nie powinna zawierać znaku null, ponieważ określa ona nazwę końca kolekcji.
3. Nazwa kolekcji nie powinna zaczynać się od przedrostka „system”. ponieważ jest to zarezerwowane dla kolekcji wewnętrznych.

4. Dobrze byłoby nie zawierać znaku „$” w nazwie kolekcji, ponieważ różne sterowniki dostępne dla bazy danych nie obsługują „$” w nazwie kolekcji.

   Podczas tworzenia nazwy bazy danych należy pamiętać o następujących kwestiach:

5. Baza danych z pustym ciągiem („”) nie jest prawidłową nazwą bazy danych.
6. Nazwa bazy danych nie może przekraczać 64 bajtów.
7. W nazwach baz danych rozróżniana jest wielkość liter, nawet w systemach plików bez rozróżniania wielkości liter. Dlatego dobrze jest zachować nazwę małymi literami.
8. Nazwa bazy danych nie może zawierać żadnego z tych znaków „/, \,.,”, *, <,>,:, |,?, $, ”. Nie może również zawierać pojedynczej spacji ani znaku null.

Po więcej informacji. Sprawdź poniższy link: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Myślę, że to wszystko osobiste preferencje. Moje preferencje wynikają z używania NHibernate w .NET z SQL Server, więc prawdopodobnie różnią się od tego, czego używają inni.

• Bazy danych: używana aplikacja .. np .: Stackoverflow
• Kolekcje: pojedyncza nazwa, co to będzie kolekcja, np .: Pytanie
• Pola dokumentu, np .: MemberFirstName

Szczerze mówiąc, nie ma to większego znaczenia, o ile jest spójne z projektem. Po prostu zabierz się do pracy i nie przejmuj się szczegółami: P

Dopóki nie otrzymamy SERVER-863 utrzymywanie jak najkrótszych nazw pól jest wskazane, szczególnie w przypadku dużej liczby rekordów.

W zależności od przypadku użycia nazwy pól mogą mieć ogromny wpływ na przechowywanie. Nie mogę zrozumieć, dlaczego nie jest to wyższy priorytet dla MongoDb, ponieważ będzie to miało pozytywny wpływ na wszystkich użytkowników. Jeśli nic więcej, możemy zacząć być bardziej opisowi z naszymi nazwami pól, bez zastanowienia się nad przepustowością i kosztami przechowywania.

Proszę głosować .