Quelles sont les conventions de dénomination pour MongoDB?

Existe-t-il un ensemble de conventions de dénomination préférées pour les droits MongoDB tels que les bases de données, les collections, les noms de champ?

Je pensais dans ce sens:

• Bases de données: composées du but (mot au singulier) et se terminent par «db» - toutes en minuscules: imagedb, resumedb, memberdb, etc.
• Collections: pluriel en minuscules: images, CV,
• Champs de document: lowerCamelCase, par exemple memberFirstName, fileName, etc.

1. Soyez bref: optimisation du stockage des petits objets , SERVER-863 . Idiot mais vrai.

2. Je suppose qu'à peu près les mêmes règles qui s'appliquent aux bases de données de relations devraient s'appliquer ici. Et après tant de décennies, il n'y a toujours pas d'accord pour savoir si les tables SGBDR doivent être nommées au singulier ou au pluriel ...

3. MongoDB parle JavaScript, utilisez donc les conventions de dénomination JS de camelCase.

4. La documentation officielle de MongoDB mentionne que vous pouvez utiliser des traits de soulignement, également un identifiant intégré est nommé _id(mais cela peut être pour indiquer qu'il _idest destiné à être privé, interne, jamais affiché ou modifié.

BASE DE DONNÉES

• affaire de chameau
• ajouter DB à la fin du nom
• rendre singulier (les collections sont plurielles)

MongoDB donne un bel exemple:

Pour sélectionner une base de données à utiliser, dans le shell mongo, émettez l'instruction use <db>, comme dans l'exemple suivant:

utiliser myDB
utiliser myNewDB

Contenu de: https://docs.mongodb.com/manual/core/databases-and-collections/#databases

COLLECTIONS

• Noms en minuscules: évite les problèmes de sensibilité à la casse, les noms de collection MongoDB sont sensibles à la casse.

• Pluriel: plus évident d'étiqueter une collection de quelque chose au pluriel, par exemple "fichiers" plutôt que "fichier"

• > Pas de séparateurs de mots: évite les problèmes où différentes personnes séparent (incorrectement) des mots (nom d'utilisateur <-> nom_utilisateur, prénom <-> prénom
  ). Celui-ci est sujet à débat selon quelques personnes
  ici, mais à condition que l'argument soit isolé des noms de collection, je ne pense pas que cela devrait l'être;) Si vous vous trouvez en train d'améliorer la
  lisibilité du nom de votre collection en ajoutant des
  traits de soulignement ou du camel Le nom est probablement trop long ou devrait utiliser des
  périodes comme il convient, ce qui est la norme pour la
  catégorisation des collections .

• Notation par points pour les collections plus détaillées: donne une indication sur la façon dont les collections sont liées. Par exemple, vous pouvez être raisonnablement sûr de pouvoir supprimer "users.pagevisits" si vous supprimez "users", à condition que les personnes qui ont conçu le schéma aient fait du bon travail.

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

Pour les collections, je suis ces modèles suggérés jusqu'à ce que je trouve la documentation officielle de MongoDB.

Même si aucune convention n'est spécifiée à ce sujet, les références manuelles sont systématiquement nommées d'après la collection référencée dans la documentation Mongo, pour les relations un-à-un. Le nom suit toujours la structure<document>_id .

Par exemple, dans une dogscollection, un document aurait des références manuelles à des documents externes nommés comme ceci:

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

Cela suit la convention Mongo de nommer _idl'identifiant de chaque document.

Convention de dénomination pour la collection

Afin de nommer une collection, quelques précautions à prendre:

1. Une collection avec une chaîne vide («») n'est pas un nom de collection valide.
2. Un nom de collection ne doit pas contenir le caractère nul car cela définit la fin du nom de collection.
3. Le nom de la collection ne doit pas commencer par le préfixe «système». car il est réservé aux collections internes.

4. Il serait bon de ne pas contenir le caractère «$» dans le nom de la collection car divers pilotes disponibles pour la base de données ne prennent pas en charge «$» dans le nom de la collection.

   Les choses à garder à l'esprit lors de la création d'un nom de base de données sont:

5. Une base de données avec une chaîne vide («») n'est pas un nom de base de données valide.
6. Le nom de la base de données ne peut pas dépasser 64 octets.
7. Les noms de base de données sont sensibles à la casse, même sur les systèmes de fichiers non sensibles à la casse. Il est donc bon de garder le nom en minuscules.
8. Un nom de base de données ne peut contenir aucun de ces caractères "/, \,.,", *, <,>,:, |,?, $, ". Il ne peut pas non plus contenir un seul espace ou un caractère nul.

Pour plus d'informations. Veuillez consulter le lien ci-dessous: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Je pense que c'est une préférence personnelle. Mes préférences proviennent de l'utilisation de NHibernate, dans .NET, avec SQL Server, donc elles diffèrent probablement de ce que les autres utilisent.

• Bases de données: l'application utilisée. Ex: Stackoverflow
• Collections: Nom unique, de quoi ce sera une collection, ex: Question
• Champs de document, ex: MemberFirstName

Honnêtement, cela n'a pas trop d'importance, du moment que c'est cohérent pour le projet. Mettez-vous au travail et ne vous inquiétez pas des détails: P

Jusqu'à ce que nous obtenions SERVER-863 est conseillé de garder les noms de champs aussi courts que possible, surtout lorsque vous avez beaucoup d'enregistrements.

Selon votre cas d'utilisation, les noms de champ peuvent avoir un impact énorme sur le stockage. Je ne comprends pas pourquoi ce n'est pas une priorité plus élevée pour MongoDb, car cela aura un impact positif sur tous les utilisateurs. Si rien d'autre, nous pouvons commencer à être plus descriptifs avec nos noms de champs, sans réfléchir à deux fois aux coûts de bande passante et de stockage.

Veuillez voter .