Trabajar con JSON anidado: aplanar, consultar y transformar datos
JSON se anida de forma natural — objetos dentro de objetos, arrays dentro de objetos, objetos dentro de arrays — porque así es como los programas modelan los datos. Las hojas de cálculo, los archivos CSV y las tablas SQL no se anidan en absoluto; son estrictamente bidimensionales, filas y columnas. El hueco entre esos dos mundos es donde entra el 'aplanado', y saber cuándo aplanar y cuándo dejar la estructura en paz es la mayor parte de lo que hace manejable el JSON anidado.
Por qué el JSON profundamente anidado se resiste a las hojas de cálculo y al SQL
Un objeto JSON con tres niveles de anidamiento y un array enterrado dentro no tiene un mapeo obvio de fila/columna — ¿qué campo se convierte en columna, y qué pasa con un campo que se repite por cada elemento del array? Pegar JSON anidado en un conversor ingenuo de 'JSON a CSV' o en el importador JSON de Excel o bien descarta los campos anidados por completo o los vuelca en una sola celda como blob serializado, y ambos resultados tiran exactamente la estructura sobre la que querrías filtrar, ordenar o consultar.
No es tanto un fallo de las herramientas como un desajuste representacional real: el JSON anidado codifica un árbol, y una hoja de cálculo o tabla SQL codifica una lista plana de registros. Pasar de uno al otro exige una decisión explícita sobre cómo manejar ese desajuste, no solo una conversión de formato.
Qué significa realmente aplanar
Aplanar transforma una estructura anidada en un objeto de un solo nivel donde cada ruta anidada se convierte en una clave, normalmente unida con un punto (`user.address.city`) o escrita en notación de corchetes (`user[address][city]`). Los elementos de los arrays reciben un índice en la ruta (`roles.0`, `roles.1`), convirtiendo una lista en un conjunto de claves direccionables individualmente. El resultado no tiene anidamiento alguno — cada valor es una simple cadena, número o booleano, y cada clave identifica unívocamente exactamente un valor hoja del documento original.
Esa propiedad — una clave por valor hoja, sin anidamiento — es exactamente lo que necesita una columna de hoja de cálculo, una fila SQL o un simple almacén de clave/valor.
Un ejemplo práctico
Toma un registro de usuario anidado típico con un objeto de dirección y un array de cadenas de roles.
{
"user": {
"id": 42,
"name": "Ada Lovelace",
"address": {
"city": "London",
"postcode": "W1"
},
"roles": ["admin", "editor"]
}
}{
"user.id": 42,
"user.name": "Ada Lovelace",
"user.address.city": "London",
"user.address.postcode": "W1",
"user.roles.0": "admin",
"user.roles.1": "editor"
}Seis claves, cero anidamiento, y cada una es una ruta directa y sin ambigüedad a un único valor original — trivialmente utilizable como seis columnas de hoja de cálculo o seis columnas en una sola fila SQL.
Cuándo aplanar y cuándo mantener el anidamiento
Aplana cuando el destino es genuinamente tabular — una exportación CSV, una hoja de cálculo, una única fila de tabla SQL, una herramienta de análisis que solo entiende columnas planas — y cuando los arrays son listas cortas de escalares (como `roles` arriba) donde una clave numerada por índice por elemento es un compromiso razonable.
Mantén el anidamiento, o reestructura en lugar de aplanar, cuando un array contiene objetos completos cuyo recuento varía por registro — un array `orders` donde cada usuario tiene un número distinto de pedidos, cada uno con varios campos propios. Aplanarlo tal cual o bien produce un conjunto distinto y desigual de columnas por registro (`orders.0.total`, `orders.1.total`, ... `orders.14.total` para tu mayor cliente) o tira la toalla y colapsa todo el array en una única celda de JSON serializado, lo cual derrota todo el propósito de aplanar. El mejor movimiento para arrays de objetos es la normalización relacional clásica: saca el array a su propia tabla/hoja con una clave foránea de vuelta al registro padre, en lugar de intentar forzarlo en columnas de la fila padre. Esto es exactamente lo que hace automáticamente la herramienta JSON to Table de JsonForge — aplana los campos escalares en columnas de la tabla y desglosa los arrays de objetos en sus propias tablas relacionadas en lugar de destrozarlos en columnas numeradas por índice.
Acceso por ruta: consultar sin aplanarlo todo
A veces no necesitas aplanar un documento entero — solo necesitas un valor de una estructura profundamente anidada. La notación de puntos (`user.address.city`) o una expresión estilo JSONPath (`$.user.address.city`, `$.roles[0]`) permite direccionar directamente un único valor anidado, que es la misma idea subyacente que aplanar, aplicada a una búsqueda en lugar de al documento completo. Es lo que impulsa `lodash.get(obj, 'user.address.city')`, la interpolación de variables de la mayoría de motores de plantillas y las herramientas de consulta JSON en general.
En la práctica, las dos técnicas se complementan: la herramienta JSON Flatten de JsonForge aplica esta transformación de rutas de puntos a un documento entero de una vez, convirtiendo cada valor anidado en una clave plana y direccionable — útil siempre que el destino sea una hoja de cálculo, un almacén simple de clave/valor o cualquier herramienta que no pueda recorrer estructuras anidadas de forma nativa.
FAQ
- ¿Cuál es la diferencia entre aplanar y simplemente serializar como cadena los campos anidados?
- Aplanar convierte cada valor anidado en su propia clave escalar de nivel superior, así que cada valor sigue siendo consultable, ordenable y filtrable de forma independiente. Serializar como cadena un campo anidado lo colapsa en un único blob de texto opaco — puedes mostrarlo, pero no puedes filtrar por un valor interno ni ordenar por él sin analizar antes la cadena de nuevo. Aplanar preserva la consultabilidad; serializar como cadena solo aplaza el problema.
- ¿Cómo se representan los arrays al aplanar JSON?
- La convención estándar es añadir el índice del array a la ruta, así que `roles: ["admin", "editor"]` se convierte en `roles.0: "admin"` y `roles.1: "editor"`. Esto funciona limpiamente para listas cortas y más o menos fijas de escalares, pero produce un conjunto desigual y en perpetuo crecimiento de claves para arrays cuya longitud varía mucho entre registros — en ese caso, una tabla relacionada aparte suele encajar mejor que claves planas indexadas.
- ¿Puede un objeto JSON aplanado volver a su forma anidada original?
- Sí — el 'desaplanado' invierte el proceso dividiendo cada clave de ruta de puntos de nuevo en sus componentes y reconstruyendo con ellos los objetos y arrays anidados, siempre que la convención de separador se haya aplicado de forma consistente y ninguna clave original contuviera un punto literal.
- ¿Es la notación de puntos la única forma de representar una clave aplanada?
- No. La notación de puntos (`user.address.city`) es la más común porque refleja cómo accederías al valor en JavaScript o Python, pero la notación de corchetes (`user[address][city]`) y las claves unidas por guiones bajos (`user_address_city`) también se usan, especialmente en herramientas dirigidas a entornos donde los puntos en nombres de columna resultan incómodos (algunos dialectos SQL, ciertas herramientas de hojas de cálculo). La convención importa menos que aplicarla con consistencia en todo el documento.
Prueba estas herramientas
Artículos relacionados
¿Qué es JSON? Una guía completa para principiantes →
JSON (JavaScript Object Notation) es un formato ligero de intercambio de datos, fácil de leer para los humanos y de analizar para las máquinas. Aprende la sintaxis, los tipos de datos y la estructura que impulsan las APIs modernas.
La historia de JSON: del 2000 al estándar de la industria →
Recorre JSON desde la idea de Douglas Crockford en 2001, pasando por su adopción por Yahoo, hasta convertirse en el estándar ECMA-404 que impulsa el 90 % de las APIs modernas.
La guía completa de JSON Schema (Draft 7) →
JSON Schema es el estándar para describir y validar la estructura de JSON. Aprende las palabras clave principales, crea un esquema de API real y aplica buenas prácticas.