Definición
Una estructura de datos es la forma en que se organizan los datos en memoria para poder trabajar con ellos.
Y hay una idea que conviene interiorizar pronto: elegir la estructura correcta suele hacer más por el rendimiento que optimizar el código que la recorre. Cambiar de estructura convierte un problema lento en uno rápido; afinar el código de una estructura mal elegida solo lo hace un poco menos lento.
Las que se usan todos los días
Array o lista. Elementos en orden, accesibles por posición. Buena para recorrer y para mantener el orden. Buscar dentro de ella obliga a recorrerla entera.
Mapa o diccionario. Pares clave→valor. Buscar por clave es instantáneo, sin importar cuántos elementos haya. Es la estructura que resuelve más problemas de rendimiento en la práctica.
Conjunto. Colección sin duplicados y sin orden garantizado. Sirve para dos cosas muy frecuentes: eliminar repetidos y comprobar si algo ya está.
Cola y pila. La cola atiende por orden de llegada; la pila, al revés — el último en entrar es el primero en salir.
Árbol. Datos jerárquicos: un menú, una estructura de carpetas, categorías con subcategorías.
Grafo. Elementos conectados entre sí sin jerarquía. Una red de relaciones.
La elección que más se repite: lista o mapa
Es la decisión práctica que aparece continuamente:
Si vas a recorrer todo y el orden importa → lista. Si vas a buscar elementos concretos por un identificador → mapa.
La diferencia no es de estilo. Buscar en una lista de 5.000 elementos exige recorrerla; en un mapa es una operación directa. Repetido dentro de un bucle, esa diferencia son segundos frente a milisegundos.
Ejemplo práctico
En un sistema de gestión, la estructura de datos decide el rendimiento de las pantallas que cruzan información.
El caso concreto: pintar un listado de 2.000 pedidos mostrando el nombre del cliente de cada uno. Con los clientes en una lista, cada pedido obliga a recorrerla buscando el suyo. Con los clientes en un mapa indexado por id, cada pedido lo encuentra directamente.
Mismo resultado en pantalla. La diferencia entre medio minuto y un instante.
Lo que aprendí: el patrón se repite tanto que ya es un reflejo — si voy a buscar lo mismo muchas veces, primero lo meto en un mapa. Es una línea de código antes del bucle y ahorra el problema entero.
Lo apliqué literalmente al construir el mapa del diccionario: 290 términos y más de mil conexiones. Averiguar los vecinos de un nodo recorriendo la lista de aristas en cada fotograma habría hecho la página inservible; precalculando un mapa de vecinos una sola vez, el dibujo es instantáneo. Ver algoritmo.
El segundo aprendizaje, sobre el conjunto: es la estructura más infravalorada. Comprobar «¿ya he procesado este?» con una lista es lento y con un conjunto es inmediato. Aparece en deduplicaciones, en control de elementos vistos y en cualquier proceso que no deba repetir trabajo — por ejemplo, al evitar que un mismo aviso se envíe dos veces.
Y una advertencia sobre memoria: meter todo en mapas acelera a costa de ocupar memoria. Con miles de registros es intrascendente; con millones hay que pensarlo, y probablemente el sitio correcto para ese cruce sea la base de datos y no la memoria del programa.
Errores comunes
- Usar listas para buscar cuando se busca muchas veces.
- Recorrer una lista dentro de un bucle que recorre otra.
- No usar conjuntos para deduplicar o para controlar lo ya visto.
- Cargar en memoria lo que la base de datos podría cruzar mejor.
- Elegir la estructura por costumbre y no por cómo se va a usar.
- Confundir la estructura con el formato. JSON es un formato de intercambio; el mapa es cómo lo tienes en memoria.
Cuándo pensar en ello
Antes de escribir el bucle, no después de que vaya lento.
La pregunta que decide casi siempre: ¿voy a recorrer esto entero, o voy a buscar cosas concretas dentro? La respuesta determina la estructura, y la estructura determina el rendimiento.
