¿Cuáles son las convenciones de nomenclatura para MongoDB?

¿Existe un conjunto de convenciones de nomenclatura preferidas para los derechos de MongoDB, como bases de datos, colecciones, nombres de campo?

Estaba pensando en estas líneas:

• Bases de datos: consisten en el propósito (palabra en singular) y terminan con "db" - todo en minúsculas: imagedb, resumedb, memberdb, etc.
• Colecciones: plural en minúsculas: imágenes, currículums,
• Campos del documento: lowerCamelCase, por ejemplo, memberFirstName, fileName, etc.

1. Manténgalos cortos: Optimizando el almacenamiento de objetos pequeños , SERVER-863 . Tonto pero cierto.

2. Creo que las mismas reglas que se aplican a las bases de datos de relaciones deberían aplicarse aquí. Y después de tantas décadas todavía no hay acuerdo sobre si las tablas RDBMS deberían llamarse singular o plural ...

3. MongoDB habla JavaScript, así que utilice las convenciones de nomenclatura JS de camelCase.

4. La documentación oficial de MongoDB menciona que puede usar guiones bajos, también se nombra el identificador incorporado _id(pero esto puede ser para indicar que _idestá destinado a ser privado, interno, nunca mostrado o editado.

BASE DE DATOS

• el caso de Carmel
• agregar DB al final del nombre
• hacer singular (las colecciones son plurales)

MongoDB establece un buen ejemplo:

Para seleccionar una base de datos para usar, en el shell mongo, emita la instrucción use <db>, como en el siguiente ejemplo:

use myDB
use myNewDB

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

COLECCIONES

• Nombres en minúscula: evita problemas de mayúsculas y minúsculas, los nombres de colecciones MongoDB distinguen entre mayúsculas y minúsculas.

• Plural: más obvio para etiquetar una colección de algo como plural, por ejemplo, "archivos" en lugar de "archivo"

• > Sin separadores de palabras: evita problemas en los que diferentes personas (incorrectamente) separan palabras (nombre de usuario <-> nombre_usuario, nombre_nombre <-> nombre
  ). Este es un tema de debate según algunas personas de
  por aquí, pero siempre que el argumento esté aislado de los nombres de las colecciones, no creo que deba serlo;) Si se encuentra mejorando la
  legibilidad del nombre de su colección agregando guiones bajos o
  camello El nombre es probablemente demasiado largo o debe usar
  puntos según corresponda, que es el estándar para la
  categorización de la colección .

• Notación de puntos para colecciones de mayor detalle: da alguna indicación de cómo se relacionan las colecciones. Por ejemplo, puede estar razonablemente seguro de que podría eliminar "users.pagevisits" si elimina "users", siempre que las personas que diseñaron el esquema hayan hecho un buen trabajo.

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

Para las colecciones, sigo estos patrones sugeridos hasta que encuentre la documentación oficial de MongoDB.

Incluso si no se especifica ninguna convención sobre esto, las referencias manuales se nombran consistentemente después de la colección referenciada en la documentación de Mongo, para las relaciones uno a uno. El nombre siempre sigue la estructura <document>_id.

Por ejemplo, en una dogscolección, un documento tendría referencias manuales a documentos externos llamados así:

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

Esto sigue la convención de Mongo de nombrar _idel identificador para cada documento.

Convención de nomenclatura para colección

Para nombrar una colección, se deben tomar algunas precauciones:

1. Una colección con una cadena vacía ("") no es un nombre de colección válido.
2. Un nombre de colección no debe contener el carácter nulo porque esto define el final del nombre de la colección.
3. El nombre de la colección no debe comenzar con el prefijo "sistema". ya que está reservado para colecciones internas.

4. Sería bueno no contener el carácter "$" en el nombre de la colección, ya que varios controladores disponibles para la base de datos no admiten "$" en el nombre de la colección.

   Las cosas a tener en cuenta al crear un nombre de base de datos son:

5. Una base de datos con una cadena vacía ("") no es un nombre de base de datos válido.
6. El nombre de la base de datos no puede tener más de 64 bytes.
7. El nombre de la base de datos distingue entre mayúsculas y minúsculas, incluso en sistemas de archivos que no distinguen entre mayúsculas y minúsculas. Por lo tanto, es bueno mantener el nombre en minúsculas.
8. El nombre de una base de datos no puede contener ninguno de estos caracteres "/, \,.,", *, <,>,:, |,?, $, ". Tampoco puede contener un solo espacio o carácter nulo.

Para más información. Por favor, consulte el siguiente enlace: http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

Creo que todo es preferencia personal. Mis preferencias provienen del uso de NHibernate, en .NET, con SQL Server, por lo que probablemente difieran de lo que otros usan.

• Bases de datos: la aplicación que se está utilizando ... por ejemplo: Stackoverflow
• Colecciones: Singular en nombre, de lo que va a ser una colección, por ejemplo: Pregunta
• Campos del documento, por ejemplo: MemberFirstName

Honestamente, no importa demasiado, siempre y cuando sea consistente para el proyecto. Simplemente trabaje y no se preocupe por los detalles: P

Hasta que tengamos SERVER-863 es aconsejable mantener los nombres de campo lo más cortos posible, especialmente cuando tiene muchos registros.

Dependiendo de su caso de uso, los nombres de campo pueden tener un gran impacto en el almacenamiento. No puedo entender por qué esto no es una prioridad más alta para MongoDb, ya que tendrá un impacto positivo en todos los usuarios. Por lo menos, podemos comenzar a ser más descriptivos con nuestros nombres de campo, sin pensar dos veces en el ancho de banda y los costos de almacenamiento.

Por favor vote .