MongoDB
Explica patrones para representar árboles y jerarquías con referencias padre, arrays de ancestros, materialized paths y estructuras anidadas.
Una jerarquía no tiene una única representación correcta en MongoDB. El modelo depende de qué consultas dominan: obtener el padre, listar hijos directos, recorrer todos los descendientes, reconstruir la ruta, mover ramas o calcular profundidad.
consulta dominante
→ representación del árbol
→ índices
→ coste de lectura y movimientoLas opciones principales son parent reference, child references, ancestors array, materialized path y recorridos con $graphLookup.
Cada nodo guarda su padre:
{
_id: categoryId,
businessId,
name: 'Cafés',
parentId: beveragesId
}Índice:
db.categories.createIndex({
businessId: 1,
parentId: 1,
name: 1
});Ventajas:
parentId;Costes:
$graphLookup;El padre guarda IDs de hijos:
{
_id: beveragesId,
childIds: [coffeeId, teaId]
}Puede acelerar lectura de hijos cuando la lista es pequeña y estable, pero introduce problemas:
No es recomendable para nodos con miles de hijos o alta concurrencia.
Cada nodo guarda su cadena de ancestros:
{
_id: espressoId,
name: 'Espresso',
ancestors: [rootId, beveragesId, coffeeId]
}Índice:
db.categories.createIndex({
businessId: 1,
ancestors: 1
});Consultar descendientes:
db.categories.find({
businessId,
ancestors: coffeeId
});Ventajas:
Costes:
Guarda una ruta serializada:
{
_id: espressoId,
path: '/root/beverages/coffee/espresso/'
}Puede consultarse por prefijo para encontrar descendientes. Es legible y útil para breadcrumbs, pero requiere:
Usar nombres en la ruta es riesgoso porque cambiar un nombre modifica identidad. Prefiere IDs o slugs estables.
Permite recorrer relaciones almacenadas como referencias:
db.categories.aggregate([
{ $match: { _id: categoryId, businessId } },
{
$graphLookup: {
from: 'categories',
startWith: '$parentId',
connectFromField: 'parentId',
connectToField: '_id',
as: 'ancestors',
maxDepth: 20,
depthField: 'depth'
}
}
]);Ventajas:
Costes:
MongoDB no impide automáticamente:
A → B → C → AAntes de mover un nodo:
En operaciones concurrentes puede necesitarse transacción o versión optimista.
Con parent reference solo cambia el nodo raíz de la rama. Con ancestors o materialized path deben actualizarse todos los descendientes.
Estrategia segura:
moving;ready;Una transacción gigante no es adecuada para miles de nodos.
Si los hijos tienen orden manual, guarda position o una clave ordenable:
{
parentId,
position: 1200
}Evita renumerar todos los hermanos en cada inserción. Puedes utilizar gaps o claves fraccionarias, pero debes definir rebalanceo.
Eliminar un padre plantea decisiones:
No ejecutes cascadas implícitas desde middleware sin límites. Procesa ramas grandes como job reanudable.
Toda consulta y relación debe incluir tenant:
{
_id: nodeId,
businessId,
parentId
}No basta validar que parentId existe; debe pertenecer al mismo negocio. Un índice compound ayuda a localizar y proteger consultas.
Parent reference.
Ancestors array o materialized path.
Parent reference + $graphLookup.
Puede requerirse cierre transitivo materializado, búsqueda especializada o rediseño por particiones.
parentId: null;$graphLookup sin profundidad máxima;$graphLookup.El patrón correcto depende de la dirección y frecuencia de navegación. Parent reference simplifica movimientos; ancestors y materialized path aceleran descendientes a cambio de actualizaciones masivas. Toda jerarquía necesita límites, validación de ciclos, estrategia de movimientos y reparación.
$graphLookup?Denormalización y datos derivados.