Los datos: hojas, bases y extracción

Una automatización sin datos no hace nada. Y como viste montando tu primer flujo, la mayor parte del trabajo real no está en la lógica: está en conseguir los datos, darles forma y guardarlos donde se puedan volver a usar.

Este capítulo va de las tres cosas.

Dónde guardar: hoja de cálculo o base de datos

La primera decisión, y la que más gente se equivoca por comodidad.

Una hoja de cálculo vale cuando los datos son pocos, los mira una persona y la estructura cambia a menudo. Es inmediata, todo el mundo sabe usarla y tu cliente puede abrirla sin que le expliques nada. Ese último punto vale más de lo que parece: un cliente que puede ver sus datos confía más.

Sus límites llegan antes de lo que crees: se vuelve lenta con volumen, no impide que alguien escriba texto donde va una fecha, y si dos procesos escriben a la vez, se pisan.

Una base de datos —incluidas las que parecen hojas pero no lo son— vale cuando hay relaciones entre cosas, cuando varios procesos escriben o cuando el volumen crece. Impone estructura, y esa rigidez que al principio molesta es lo que evita que en seis meses tengas un vertedero.

La regla práctica: empieza en hoja, migra a base cuando duela. Y para que migrar sea posible, no repartas tu lógica por dentro de la hoja: si la automatización depende de veinte fórmulas escondidas en celdas, migrar es rehacerlo todo. La lógica va en el flujo, la hoja solo guarda.

El identificador único: la decisión que se paga cara

Cada cosa que guardes necesita un identificador estable que no cambie nunca.

No uses el nombre. No uses el correo. Las personas cambian de correo, escriben su nombre de tres formas distintas y a veces son dos personas con el mismo nombre. Usa un identificador propio que generes tú, o el que te dé el sistema de origen.

Este es probablemente el fallo que más caro sale a largo plazo, porque no se nota hasta que ya tienes miles de registros duplicados y ningún criterio fiable para saber cuáles son el mismo.

Y con él viene su pareja: hacer las escrituras idempotentes. Que ejecutar dos veces el mismo proceso no cree dos registros. En cuanto una automatización se ejecuta sola y reintenta errores, esto deja de ser elegancia y pasa a ser necesidad.

Sacar datos de donde no hay puerta

A veces la información que necesitas no tiene una vía de acceso ordenada. Hay tres caminos, y conviene intentarlos en este orden:

Primero, la vía oficial. Muchos servicios ofrecen acceso programático y casi nadie lo mira antes de ponerse a raspar páginas. Es más estable, más rápido y no te van a bloquear.

Segundo, la exportación. Un montón de sistemas dejan descargar un fichero. Si el proceso es diario y no de cada minuto, una descarga programada resuelve el problema sin complicaciones.

Tercero, y solo si no queda otra, extraer de la página. Funciona, y se rompe. Cambia el diseño de la web y tu automatización deja de funcionar sin avisar — o peor, sigue funcionando y devuelve basura. Si acabas aquí, monta siempre una comprobación de que lo extraído tiene sentido, y avisa cuando no.

Y sobre lo legal y lo ético, que no es un adorno: mira las condiciones de uso del sitio, respeta lo que indique el fichero `robots.txt`, no machaques un servidor ajeno con peticiones, y ten mucho cuidado con datos personales. En Europa, recopilar datos de personas —aunque estén publicados— te mete de lleno en el reglamento de protección de datos, con obligaciones reales. Que sea técnicamente posible no lo hace legal, y un cliente serio te va a preguntar.

Documentos: de PDF a datos

El caso que más se paga en negocios pequeños: facturas, albaranes, contratos, informes. Llegan en PDF o escaneados y alguien los copia a mano.

El proceso tiene tres etapas y conviene no mezclarlas:

Extraer el texto. Si el PDF es digital, sale limpio. Si es un escaneo, hace falta reconocimiento óptico, y ahí la calidad de la imagen manda sobre todo lo demás.

Estructurar. Aquí es donde un modelo de lenguaje brilla de verdad: dale el texto y pídele los campos concretos, en formato fijo, con un valor explícito cuando falte alguno. Es exactamente lo que preparaste en el capítulo dos.

Validar. Un total que no cuadra, una fecha imposible, un identificador fiscal con formato incorrecto. Esta etapa no es opcional: un modelo puede leer mal un número y escribirlo con toda la seguridad del mundo.

Y una decisión de diseño que te va a salvar: guarda siempre el documento original junto al dato extraído. El día que alguien discuta una cifra, poder ir al original es la diferencia entre resolverlo en un minuto y no poder defenderte.