Czy istnieje konwencja dotycząca gromadzenia nazw w MongoDB?


Odpowiedzi:


90

Ogólne konwencje to:

  • Nazwy małymi literami: pozwala to uniknąć problemów z rozróżnianiem wielkości liter, ponieważ nazwy kolekcji MongoDB uwzględniają wielkość liter .
  • Liczba mnoga : bardziej oczywiste jest oznaczanie zbioru jako liczby mnogiej, np. „Pliki” zamiast „plik”
  • Brak separatorów słów : pozwala uniknąć problemów, w których różne osoby (niepoprawnie) oddzielają słowa (nazwa użytkownika <-> nazwa_użytkownika, imię <-> imię). Ten temat jest przedmiotem debaty według kilku osób tutaj, ale pod warunkiem, że argument jest ograniczony do nazw kolekcji, nie sądzę, aby tak było;) Jeśli zauważysz, że poprawisz czytelność nazwy swojej kolekcji, dodając podkreślenia lub wielbłąd nazwa zbioru jest prawdopodobnie zbyt długa lub powinna zawierać odpowiednie okresy, co jest standardem klasyfikacji kolekcji.
  • Notacja kropkowa dla kolekcji o większej szczegółowości : daje pewne wskazówki dotyczące powiązań kolekcji. Na przykład możesz być dość pewny, że możesz usunąć „users.pagevisits”, jeśli usuniesz „users”, pod warunkiem, że osoby, które zaprojektowały schemat, wykonały dobrą robotę;)

Przykłady:

users
pagevisits
users.pagevisits

Konwencje nazewnictwa pól (powinny) być zgodne z tą samą logiką, chociaż są one dość powszechne.


33
Muszę się z tobą nie zgodzić, jeśli chodzi o całą sprawę „bez separatorów słów”, szczególnie jeśli używasz MongoDB z Pythonem. Podkreślenia zamiast spacji są bardzo czytelne, co jest jedną z najbardziej pożądanych cech kodu, schematu i tym podobnych.
Noah McIlraith

2
Subiektywność to piękna rzecz;) Jeśli natkniesz się na nazwy pól lub kolekcji, które zawierają tak wiele słów, które podkreślają, poprawiają czytelność kodu, prawdopodobnie powinieneś ponownie rozważyć nazwę jako całość. Oczywiście dla każdego. Uważam, że kwestia możliwych niespójności w tym, jakie słowa są rozdzielane, jest znacznie większa. Brak separatorów słów jest względnie agnostykiem językowym. Tam, gdzie wolisz podkreślenia, programista Java prawdopodobnie wolałby okładki na wielbłądach, a to szybko staje się bałaganiarskie.
Remon van Vliet,

7
Liczba pojedyncza zamiast liczby mnogiej, w przeciwnym razie odwzorowuje obiekty, takie jak Pojos w liczbie mnogiej, a otrzymasz klasę Users! zamiast klasy użytkownika
ricardoespsanto

4
@Ricky Przypuszczam, że to jest. Odpowiedź, do której się odnosisz, to pomieszanie tych samych pojęć, które są tutaj pomieszane. Nazywanie jednostki a nazywanie kolekcji. Nikt nie użyłby „Klienci” jako nazwy jednostki, jak sugeruje autor tej odpowiedzi, mimo że mógłby użyć CUSTOMERS jako nazwy tabeli SQL. Jak mówisz, jest to niezwykle subiektywna dyskusja. Dopóki jest spójny w całej bazie kodu, nie powinno być zbyt dużego problemu.
Remon van Vliet

3
Myślę, że liczba pojedyncza ma większy sens, ponieważ implikowana jest liczba mnoga. I jak mówi @Ricky, ten standard został ustanowiony w sql dawno temu. stackoverflow.com/questions/338156
steampowered

32

Po prostu unikaj używania łączników w nazwach kolekcji.

Dzieje się tak tylko dlatego, że jeśli użyjesz kliknięcia z dwóch poniższych wywołań, pierwsze to nieprawidłowy JavaScript:

db.foo-bar.find();
db['foo-bar'].find();

Oba są funkcjonalnie identyczne, ale drugi jest nieco bardziej irytujący w pisaniu i nie uzupełnia tabulatorów.

Poza tym zalety / wady zależą od tego, jak korzystasz z kolekcji. Konsekwencja jest ważniejsza niż konwencja, którą wybierzesz.


Czy :poprawne są nazwy kolekcji w przestrzeni nazw, jak w foo:bar?
rafian

wszystko jest ważne dla mongo. np. db["\n"].insert({});- brak błędu. Kwestie, które należy wziąć pod uwagę, to głównie wygoda ze sterownikiem, z którego korzystasz.
AD7six

1
Zmieniło się to w wersji 2.2 w systemie Windows: / \. „* <>: |? nie są już ważne - patrz docs.mongodb.org/manual/release-notes/2.2/…
toong

5
@toong, to dotyczy nazw baz danych , a nie kolekcji.
BorisOkunskiy

19

Na stronie http://docs.mongodb.org/manual/reference/limits/ podano, że nazwy kolekcji powinny zaczynać się od podkreślenia („_”) lub litery i nie mogą:

  • zawierać $.
  • być pustym ciągiem znaków (np. „”).
  • zawierać znak null.
  • zacznij od systemu. prefiks. (Zarezerwowane do użytku wewnętrznego.)

Jeśli jednak zastosujesz się do tej reguły i utworzysz kolekcję z „_” jako literą początkową, na przykład „_TWII”, napotkasz kłopoty, gdy będziesz chciał usunąć kolekcję. Zobacz poniższy test i zobacz, jak to naprawić. Kolekcja „_TWII” została utworzona pod bazą „people”.

> show collections
_TWII
employees
system.indexes
> db._TWII.drop()
2015-02-19T16:34:56.738-0800 TypeError: Cannot call method 'drop' of undefined

> use admin
switched to db admin

> db.runCommand({renameCollection:"people._TWII",to:"people.TWII"})
{ "ok" : 1 }
> use people
switched to db people
> show collections
TWII
employees
system.indexes
> db.TWII.drop()
true
> show collections
employees
system.indexes
> 

Skrót do usuwania kolekcji _TWII z bazy danych „people”:

> db.createCollection('^TWII')
{ "ok" : 1 }
> db.getCollection('^TWII').drop()
true

0

MongoDB ma pewne konwencje nazewnictwa. Jedną z nich jest to, że w nazwach baz danych wielkość liter nie ma znaczenia. Ponadto mongo użyje liczby mnogiej nazwy kolekcji, jeśli nie zostanie określona. „kurs” stanie się „kursami”.

Ponieważ w nazwach baz danych w MongoDB nie jest rozróżniana wielkość liter, nazwy baz danych nie mogą różnić się tylko wielkością znaków.

Z ich powodu spróbuj nazwać całą swoją kolekcję małymi literami i bez znaków specjalnych. Unikniesz wielu błędów - zwłaszcza jeśli używasz Mongoose. Mongoose ma dziwną specyfikę zapytań.

Na przykład, jeśli masz kolekcję o nazwie „kursy”, oto jak musisz uporządkować swój model:

const LawModel = mongoose.model(
  "course",
  new mongoose.Schema({
    id: String,
    name: String,

  }),

Zauważ, że „kurs” jest liczbą pojedynczą? Mongoose użyje liczby mnogiej, dlatego możesz zobaczyć pustą tablicę „[]”. -> pytasz o nieistniejącą kolekcję.

Spróbuj zmienić nazwę i dostosować model.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.