MongoDB
Explica cómo consultar y actualizar subdocumentos con dot notation, distinguir igualdad completa de campos individuales y evitar reemplazos accidentales.
Los documentos anidados permiten agrupar datos relacionados dentro de un documento. utiliza rutas separadas por puntos para consultar, proyectar, actualizar e indexar subcampos sin comparar el subdocumento completo.
{
customer: {
id: ObjectId('...'),
nameAtPurchase: 'Laura Gómez'
},
deliveryAddress: {
city: 'Bogotá',
countryCode: 'CO'
}
}Consulta por subcampo:
db.orders.find({
'customer.id': customerId,
'deliveryAddress.city': 'Bogotá'
});Un subdocumento conserva estructura y ownership. Sin anidación, los campos pueden perder contexto:
{
customerId,
customerName,
deliveryCity,
deliveryCountryCode
}La forma plana no siempre es incorrecta, pero la forma anidada comunica que los campos forman una unidad y permite validar, proyectar y actualizar esa unidad con rutas claras.
Esta query compara el subdocumento completo:
db.products.find({
dimensions: {
width: 10,
height: 20
}
});La igualdad exacta exige que la estructura y el orden de campos sean compatibles. Si el documento contiene un campo adicional o un orden distinto, puede no coincidir.
Normalmente es más robusto:
db.products.find({
'dimensions.width': 10,
'dimensions.height': 20
});Ahora cada condición se aplica a una ruta concreta.
db.orders.find(
{ businessId },
{
'customer.nameAtPurchase': 1,
'deliveryAddress.city': 1,
total: 1
}
);Projection puede devolver solo subcampos. El resultado conserva estructura anidada, no convierte automáticamente las rutas en propiedades planas.
Actualizar un subcampo:
db.orders.updateOne(
{ _id: orderId, businessId },
{
$set: {
'deliveryAddress.instructions': 'Llamar al llegar',
updatedAt: new Date()
}
}
);Usar $set sobre la ruta preserva los demás campos del subdocumento.
En cambio:
db.orders.updateOne(
{ _id: orderId },
{
$set: {
deliveryAddress: {
instructions: 'Llamar al llegar'
}
}
}
);reemplaza todo deliveryAddress y puede eliminar city, line1 y countryCode.
Si customer o customer.id no existe, la query por esa ruta no encuentra una coincidencia normal. Debes distinguir:
{ 'customer.id': { $exists: false } }de:
{ 'customer.id': null }Durante migraciones pueden coexistir documentos con:
{ customerId: ObjectId('...') }
{ customer: { id: ObjectId('...') } }El lector temporal puede soportar ambas formas, pero debe existir un plan para converger.
Dot notation atraviesa arrays:
{ 'items.productId': productId }Esto coincide si algún elemento tiene ese productId.
Pero dos condiciones pueden cumplirse en elementos diferentes:
{
'items.productId': productA,
'items.quantity': { $gte: 5 }
}Para exigir que pertenezcan al mismo item:
{
items: {
$elemMatch: {
productId: productA,
quantity: { $gte: 5 }
}
}
}db.orders.createIndex({
businessId: 1,
'customer.id': 1,
createdAt: -1
});El índice sigue una query shape concreta. Indexar cada ruta anidada aumenta coste de escritura y almacenamiento.
Si la ruta atraviesa un array, el índice se vuelve multikey. Eso cambia tamaño, límites y posibilidades de covered query.
Una estructura como:
business.settings.sales.checkout.payment.rules...puede ser técnicamente válida, pero difícil de:
La profundidad debe representar boundaries reales, no imitar toda la jerarquía del código.
Versiones modernas permiten ciertos usos que antes estaban restringidos, pero siguen siendo nombres problemáticos para schemas de aplicación porque colisionan con dot notation y operadores.
Evita diseñar campos como:
{
'customer.name': 'Laura',
'$status': 'pending'
}si puedes representar la estructura correctamente.
Actualizar el estado de un item específico:
db.orders.updateOne(
{
_id: orderId,
businessId,
'items.productId': productId
},
{
$set: {
'items.$.status': 'prepared',
updatedAt: new Date()
}
}
);El operador posicional $ se relaciona con el elemento que coincidió en el filtro. Para múltiples elementos o condiciones más complejas se utilizan $[] y array filters.
Si customer es null, customer.id no existe como ruta útil. Validation debería impedir formas ambiguas.
Actualizar el objeto completo puede borrar campos concurrentes o nuevos.
customer.id como string en unos documentos y ObjectId en otros rompe queries e índices coherentes.
Dot notation sin $elemMatch puede combinar elementos distintos.
Añadir un array a una ruta ya indexada puede cambiar el comportamiento del índice y sus restricciones.
Depende de forma y orden exactos.
Elimina campos no incluidos.
Añade complejidad sin mejorar ownership o acceso.
La semántica de matching cambia.
Aumenta coste sin beneficio comprobado.
explain() sobre rutas indexadas.$type.Dot notation es la forma principal de trabajar con rutas anidadas. Permite precisión sin comparar o reemplazar todo el subdocumento. Su semántica cambia al atravesar arrays, campos missing y tipos inconsistentes, por lo que debe diseñarse junto con schema e índices.
address.city y reemplazar address?$elemMatch?Arrays.