Trabajar con JSON anidado: aplanar, consultar y transformar datos
JSON anida objetos dentro de objetos, arrays dentro de objetos y objetos dentro de arrays, porque así modelan los datos los programas. Las hojas de cálculo, los archivos CSV y las tablas SQL no anidan nada; tienen dos dimensiones, filas y columnas. El aplanado tiende el puente entre ambos mundos, y casi todo el trabajo con JSON anidado consiste en saber cuándo aplanar y cuándo dejar la estructura como está.
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 no tiene un mapeo obvio de fila/columna. ¿Qué campo se convierte en columna, y qué pasa con un campo que se repite en cada elemento del array? Pega JSON anidado en un conversor ingenuo de 'JSON a CSV' o en el importador JSON de Excel, y o bien descarta los campos anidados o los vuelca en una sola celda como blob serializado. Ambos resultados tiran la estructura sobre la que querí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 aplanar
Aplanar transforma una estructura anidada en un objeto de un solo nivel donde cada ruta anidada se convierte en una clave, 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`), y así una lista se convierte en un conjunto de claves direccionables una a una. El resultado no tiene anidamiento: cada valor es una cadena, número o booleano simple, y cada clave identifica un único valor hoja del documento original.
Una columna de hoja de cálculo, una fila SQL o un almacén simple de clave/valor necesitan esa propiedad: una clave por valor hoja, sin anidamiento.
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 sin ambigüedad a un único valor original. Puedes usarlas 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 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 elemento es un compromiso razonable.
Mantén el anidamiento, o reestructura, cuando un array contiene objetos completos cuyo número varía por registro. Piensa en un array `orders` donde cada usuario tiene un número distinto de pedidos, cada uno con varios campos. Aplanarlo tal cual da a cada registro un conjunto de columnas distinto y desigual (`orders.0.total`, `orders.1.total`, ... `orders.14.total` para tu mayor cliente) o colapsa el array entero en una celda de JSON serializado, y el aplanado pierde su sentido. Para arrays de objetos, usa la normalización relacional clásica: saca el array a su propia tabla/hoja con una clave foránea hacia el registro padre. La herramienta JSON to Table de JsonForge lo hace por ti. Aplana los campos escalares en columnas de la tabla y separa los arrays de objetos en sus propias tablas relacionadas en lugar de destrozarlos en columnas numeradas.
Acceso por ruta: consultar sin aplanarlo todo
A veces necesitas un solo valor de una estructura anidada en profundidad, no un documento aplanado. La notación de puntos (`user.address.city`) o una expresión estilo JSONPath (`$.user.address.city`, `$.roles[0]`) direcciona un único valor anidado directamente. El aplanado aplica la misma idea a todo el documento; una ruta la aplica a una búsqueda. `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 funcionan así.
Las dos técnicas se complementan. La herramienta JSON Flatten de JsonForge aplica la transformación de rutas de puntos a todo un documento de una vez y convierte cada valor anidado en una clave plana. Úsala cuando el destino sea una hoja de cálculo, un almacén simple de clave/valor o una herramienta que no pueda recorrer estructuras anidadas.
FAQ
- ¿En qué se diferencia aplanar de serializar como cadena los campos anidados?
- Aplanar convierte cada valor anidado en su propia clave escalar de nivel superior, así que puedes seguir consultando, ordenando y filtrando cada valor. Serializar como cadena un campo anidado lo colapsa en un único blob de texto opaco. Puedes mostrarlo, pero no filtrar por un valor interno ni ordenar por él sin volver a analizar la cadena. Serializar aplaza el problema que el aplanado resuelve.
- ¿Cómo se representan los arrays al aplanar JSON?
- La convención estándar añade el índice del array a la ruta, así que `roles: ["admin", "editor"]` se convierte en `roles.0: "admin"` y `roles.1: "editor"`. Funciona bien para listas cortas y más o menos fijas de escalares. Para arrays cuya longitud varía mucho entre registros, produce un conjunto de claves desigual y creciente, y una tabla relacionada aparte encaja mejor.
- ¿Puede un objeto JSON aplanado volver a su forma anidada original?
- Sí. El 'desaplanado' divide cada clave de ruta de puntos en sus partes y reconstruye los objetos y arrays anidados, siempre que hayas aplicado la convención de separador 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.