MongoDB
Controla qué campos devuelve una consulta mediante proyecciones de inclusión, exclusión y rutas anidadas para reducir transferencia y exposición de datos.
La define qué campos devuelve MongoDB después de encontrar un documento. No cambia qué documentos coinciden; cambia la forma y cantidad de información que sale del servidor.
db.orders.find(
{
businessId,
status: 'pending'
},
{
projection: {
customer: 1,
total: 1,
status: 1,
createdAt: 1
}
}
);La proyección es parte del access pattern porque afecta payload, serialización, exposición de datos y, en algunos casos, la posibilidad de resolver una query únicamente desde un índice.
Un documento puede contener información útil para persistencia pero innecesaria o sensible para una operación concreta:
{
_id,
businessId,
customer,
items,
payment,
internalNotes,
audit,
createdAt
}Un listado quizá solo necesita cliente, total y fecha. Recuperar el documento completo introduce:
Projection reduce esos costes, aunque no convierte automáticamente una query en covered ni evita todo acceso al documento.
Una proyección de inclusión especifica campos que deben regresar:
{
customer: 1,
total: 1,
createdAt: 1
}MongoDB incluye _id por defecto, salvo que se excluya explícitamente:
{
_id: 0,
customer: 1,
total: 1,
createdAt: 1
}Una proyección de exclusión elimina campos:
{
internalNotes: 0,
paymentToken: 0
}Por regla general no se mezclan inclusión y exclusión en la misma proyección, excepto el tratamiento especial de _id.
Para APIs públicas suele ser más seguro incluir explícitamente campos permitidos que excluir una lista de secretos. Si mañana aparece un nuevo campo sensible, una allowlist de inclusión no lo expone accidentalmente.
Dot notation selecciona subcampos:
{
'customer.nameAtPurchase': 1,
'deliveryAddress.city': 1,
total: 1
}El resultado conserva estructura anidada:
{
customer: {
nameAtPurchase: 'Laura Gómez'
},
deliveryAddress: {
city: 'Bogotá'
},
total: Decimal128('37800.00')
}No convierte automáticamente las rutas en propiedades planas.
Para arrays existen operadores de proyección específicos.
Devuelve una parte del array:
{
recentEvents: { $slice: 5 }
}Puede utilizarse para limitar un subset embebido, pero no corrige un array ilimitado. El documento completo sigue creciendo y el índice multikey mantiene su coste.
Puede proyectar el primer elemento que cumple una condición:
{
items: {
$elemMatch: {
productId
}
}
}Esto no equivale a filtrar todos los elementos coincidentes. Si necesitas transformar o conservar múltiples elementos, aggregation con $filter puede ser más apropiada.
En contextos compatibles, devuelve el primer elemento que coincide con la condición de query. Su semántica depende del filtro y puede ser difícil de mantener. Para respuestas complejas, una pipeline suele resultar más explícita.
Projection trabaja en la base. Un DTO trabaja en la frontera de la aplicación.
MongoDB projection
→ limita campos BSON devueltos
DTO / response mapper
→ renombra, convierte, deriva y autoriza salidaEjemplo:
type OrderResponse = {
id: string;
customerName: string;
total: string;
createdAt: string;
};El mapper todavía debe:
ObjectId a string;Decimal128 sin perder precisión;customerName;Projection no reemplaza esa capa.
Una query puede ser covered cuando filtro y campos devueltos están disponibles en el índice y MongoDB no necesita hacer FETCH del documento.
Query:
db.orders.find(
{
businessId,
status: 'pending'
},
{
projection: {
_id: 0,
total: 1,
createdAt: 1
}
}
).sort({ createdAt: -1 });Índice candidato:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1,
total: 1
});Agregar campos al índice para cubrir queries tiene costes:
No conviertas todos los índices en “covering indexes” sin medir beneficio.
Una proyección pequeña reduce red y serialización. Sin embargo, si el plan necesita leer el documento para comprobar filtros o recuperar un campo no indexado, seguirá existiendo FETCH.
explain('executionStats') ayuda a verificar:
FETCH;No deduzcas cobertura solo porque la proyección parece pequeña.
En find, projection tradicional selecciona campos. Para renombrar, calcular o transformar se utiliza frecuentemente aggregation:
db.orders.aggregate([
{
$match: {
businessId,
status: 'pending'
}
},
{
$project: {
_id: 0,
id: { $toString: '$_id' },
customerName: '$customer.nameAtPurchase',
total: 1,
createdAt: 1
}
}
]);Aun así, serializar Decimal128 y decidir el contrato público puede pertenecer a la aplicación.
Projection limita exposición accidental, pero no autoriza.
Consulta insegura:
db.orders.findOne({ _id: orderId }, { projection: safeFields });Aunque la salida sea pequeña, podría leer una orden de otro tenant. El filtro debe incluir scope:
db.orders.findOne(
{
_id: orderId,
businessId: session.businessId
},
{
projection: safeFields
}
);La autorización debe decidir qué recurso puede leer el actor; projection decide qué parte devolver.
Permitir que el cliente envíe cualquier lista de campos puede exponer información y crear queries difíciles de optimizar.
Mejor:
const views = {
summary: {
customer: 1,
total: 1,
status: 1,
createdAt: 1
},
detail: {
customer: 1,
items: 1,
total: 1,
status: 1,
createdAt: 1
}
} as const;La API acepta una vista conocida, no paths arbitrarios.
Si un campo proyectado no existe, simplemente no aparece. El mapper debe tolerar versiones antiguas o validation debe evitar missing.
Aparece como null y debe diferenciarse de missing según el contrato.
Proyectar el array completo puede dominar el payload. $slice o una colección separada pueden ser necesarios.
Una estrategia de exclusión puede exponerlo accidentalmente. La inclusión explícita reduce ese riesgo.
Una query puede dejar de utilizar el índice esperado aunque los campos estén presentes.
mongos puede necesitar recibir y combinar resultados de shards. Reducir campos ayuda red interna y externa, pero no elimina scatter-gather.
Acopla API, aumenta payload y expone internals.
Ocultar campos no impide leer recursos ajenos.
Aumenta coste de escritura para perseguir cobertura marginal.
Genera errores o semántica confusa.
Selecciona estructura; no define por sí sola un DTO.
El documento sigue teniendo problemas de crecimiento y working set.
explain().FETCH.Projection es una herramienta de consulta y rendimiento, no un contrato público completo. Reduce campos, red y exposición, y puede permitir covered queries. Debe diseñarse junto con filtros, índices, DTOs y autorización.
_id tiene tratamiento especial?explain()?Ordenamiento y paginación.