Quali sono le convenzioni di denominazione per MongoDB?

Esiste una serie di convenzioni di denominazione preferite per le entità MongoDB come database, raccolte, nomi di campi?

Stavo pensando in questo modo:

• Database: consistono nello scopo (parola in singolare) e terminano con "db" - tutto minuscolo: imagedb, resumedb, memberdb, ecc.
• Collezioni: plurale in minuscolo: immagini, curriculum,
• Campi del documento: lowerCamelCase, ad esempio memberFirstName, fileName, ecc

1. Per farla breve: ottimizzazione dello stoccaggio di piccoli oggetti , SERVER-863 . Stupido ma vero.

2. Immagino che le stesse regole che si applicano ai database delle relazioni dovrebbero essere applicate qui. E dopo così tanti decenni non c'è ancora accordo sul fatto che le tabelle RDBMS debbano essere nominate singolari o plurali ...

3. MongoDB parla JavaScript, quindi utilizza le convenzioni di denominazione JS di camelCase.

4. La documentazione ufficiale di MongoDB menziona che è possibile utilizzare caratteri di sottolineatura, anche l'identificatore incorporato è chiamato _id(ma questo potrebbe essere per indicare che _idè destinato a essere privato, interno, mai visualizzato o modificato.

BANCA DATI

• camelCase
• aggiungi DB alla fine del nome
• rendere singolare (le raccolte sono plurali)

MongoDB afferma un bell'esempio:

Per selezionare un database da utilizzare, nella shell mongo, emettere l'istruzione use <db>, come nell'esempio seguente:

usa myDB
usa myNewDB

Contenuto da: https://docs.mongodb.com/manual/core/database-and-collections/#d Database

COLLEZIONI

• Nomi minuscoli: evita problemi di maiuscole e minuscole, i nomi delle raccolte MongoDB fanno distinzione tra maiuscole e minuscole.

• Plurale: più ovvio etichettare una raccolta di qualcosa come plurale, ad esempio "file" anziché "file"

• > Nessun separatore di parole: evita problemi in cui persone diverse (erroneamente) separano parole (nome utente <-> nome_utente, nome_1 <->
  nome). Questo è in discussione secondo alcune persone
  qui intorno, ma a condizione che l'argomento sia isolato dai nomi delle raccolte, non penso che dovrebbe essere;) Se ti ritrovi a migliorare la
  leggibilità del nome della tua raccolta aggiungendo caratteri di sottolineatura o
  cammello il nome è probabilmente troppo lungo o dovrebbe usare i
  periodi appropriati, che è lo standard per la
  categorizzazione delle raccolte .

• Notazione a punti per raccolte con dettagli più alti: fornisce alcune indicazioni su come le raccolte sono correlate. Ad esempio, puoi essere ragionevolmente sicuro di poter eliminare "users.pagevisits" se hai eliminato "utenti", a condizione che le persone che hanno progettato lo schema abbiano fatto un buon lavoro.

Contenuto da: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Per le raccolte sto seguendo questi schemi suggeriti fino a quando non trovo la documentazione ufficiale di MongoDB.

Anche se non viene specificata alcuna convenzione al riguardo, i riferimenti manuali prendono costantemente il nome dalla raccolta referenziata nella documentazione Mongo, per le relazioni uno a uno. Il nome segue sempre la struttura <document>_id.

Ad esempio, in una dogsraccolta, un documento avrebbe riferimenti manuali a documenti esterni chiamati in questo modo:

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

Ciò segue la convenzione Mongo di nominare _idl'identificatore per ogni documento.

Convenzione di denominazione per la raccolta

Per nominare una collezione, alcune precauzioni da prendere:

1. Una raccolta con stringa vuota (“”) non è un nome di raccolta valido.
2. Un nome di raccolta non deve contenere il carattere null perché definisce la fine del nome della raccolta.
3. Il nome della raccolta non deve iniziare con il prefisso "sistema". in quanto riservato alle collezioni interne.

4. Sarebbe bene non contenere il carattere "$" nel nome della raccolta poiché i vari driver disponibili per il database non supportano "$" nel nome della raccolta.

   Le cose da tenere a mente durante la creazione di un nome di database sono:

5. Un database con stringa vuota (“”) non è un nome di database valido.
6. Il nome del database non può contenere più di 64 byte.
7. Il nome del database fa distinzione tra maiuscole e minuscole, anche su file system non sensibili al maiuscolo / minuscolo. Quindi è bene mantenere il nome in minuscolo.
8. Un nome di database non può contenere nessuno di questi caratteri “/, \,.,“, *, <,>,:, |,?, $, ”. Inoltre, non può contenere uno spazio singolo o un carattere null.

Per maggiori informazioni. Si prega di controllare il seguente link: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Penso che sia tutta una preferenza personale. Le mie preferenze derivano dall'utilizzo di NHibernate, in .NET, con SQL Server, quindi probabilmente differiscono da ciò che usano gli altri.

• Database: l'applicazione in uso. Es: Stackoverflow
• Collezioni: singolare nel nome, che cosa sarà una raccolta, ad esempio: Domanda
• Campi del documento, ad esempio: MemberFirstName

Onestamente, non importa troppo, purché sia ​​coerente per il progetto. Basta andare al lavoro e non sudare i dettagli: P

Fino a quando non avremo SERVER-863, è consigliabile mantenere i nomi dei campi il più corti possibile soprattutto se si dispone di molti record.

A seconda del caso d'uso, i nomi dei campi possono avere un impatto enorme sulla memoria. Non riesco a capire perché questa non sia una priorità più alta per MongoDb, poiché ciò avrà un impatto positivo su tutti gli utenti. Se non altro, possiamo iniziare a essere più descrittivi con i nomi dei nostri campi, senza pensare due volte a larghezza di banda e costi di archiviazione.

Per favore, vota .