Datos y persistencia

Contexto

Por un lado, datos estructurados que alimentan informes y visualización: en Altia trabajé con Power BI, modelos dimensionales y calidad del modelo para que lo que se muestra sea coherente con lo que negocio espera medir. Por otro, aplicaciones que dependen de consistencia transaccional: en proyectos propios (el caso más claro es Fat & Happy POS, DAM sobre MariaDB) el dato vive en tablas, reglas y consultas que tienen que aguantar el uso real del producto, no solo un prototipo.

Problema

Consultas frágiles o que escalan mal rompen informes o pantallas cuando sube el volumen. Los esquemas poco evolutivos frenan el producto: cada cambio de negocio se convierte en parche. La desalineación entre dato operativo y dato útil para negocio es la que genera reuniones eternas: el sistema registra una cosa, el cuadro muestra otra, y nadie sabe cuál es la fuente de verdad. Sin criterio, también aparece estado duplicado entre hojas manuales y base de datos.

Qué resolvía el sistema o proyecto

Un mismo principio en dos escenarios: que el modelo y el acceso al dato permitan decidir con claridad. En Altia, modelos y flujos hacia reporting con dimensiones y métricas que se puedan explicar; en aplicaciones Java propias, esquema relacional, SQL u ORM alineados con reglas de negocio explícitas y migraciones que no bloqueen el producto. El objetivo es que lo transaccional y lo analítico, cuando conviven, no se contradigan sin que alguien lo sepa.

Mi rol

Modelado y consultas: diseño o revisión de esquema, índices cuando el acceso lo justifica, y consultas que no solo “pasan en vacío”. Interpretación de necesidades: traducir lo que pide negocio o el informe a tablas, relaciones y métricas que tengan sentido (en Altia sin publicar aquí dashboards ni datos de clientes). En proyectos propios, persistencia integrada con el backend: cómo las entidades y transacciones reflejan el uso real. Me importa la relación entre estructura y uso del dato: si el modelo no se corresponde con cómo se consulta o se informa, el fallo es de diseño, no solo de “una query mala”.

Stack

SQL como lenguaje común: consultas, migraciones y razonamiento sobre integridad. En entornos relacionales he trabajado con MariaDB y MySQL en proyectos propios, y con SQL Server donde el contexto lo exigía; el criterio no es el logo del motor, sino restricciones, rendimiento y operación del entorno. MongoDB solo cuando el acceso por documento encajaba de verdad con el problema, no como sustituto por moda.

En el lado analítico, Power BI en Altia junto con modelado dimensional: tablas de hechos y dimensiones, relaciones explícitas y métricas definidas para que el informe sea auditable. En el lado de aplicación, persistencia relacional coordinada con el código (ORM o SQL directo según módulo), siempre con la idea de que el esquema y las reglas en base sostienen lo que la UI o la API prometen.

Decisiones técnicas

• Motor según contexto: relacional por defecto cuando el dominio es transaccional; documental solo con justificación clara de acceso y forma de los datos.
• Esquema mantenible: normalización razonable frente a duplicar estado que luego hay que reconciliar; migraciones acotadas en piezas calientes frente a paradas largas.
• Operativo frente a representación: dimensiones y métricas explícitas en BI; en OLTP, restricciones en base cuando la regla es estable, no solo validación en aplicación.
• Evitar acoplamiento tóxico: que la aplicación no arrastre años de mal modelo; y que el reporting no invente agregados que contradigan el sistema sin documentarlo.

Restricciones o NDA

Sin volúmenes reales, dumps, esquemas completos de entornos productivos ni material identificable de clientes de consultoría.

Resultado o aprendizaje

Informes y consultas más explicables cuando el modelo refleja reglas de negocio claras. Aprendizaje que aplico en ambos frentes: medir y perfilar antes de optimizar a ciegas; en BI y en OLTP el coste de un modelo ambiguo se paga en tiempo de equipo, no solo en CPU.