Lo que nadie te cuenta sobre diseñar una base de datos desde cero

Cuando decidí construir mi propio sistema para la empresa 3PL donde trabajo, no tenía experiencia en desarrollo de software. Tenía algo distinto: conocía la operación por dentro.

Sabía exactamente qué datos importaban, cuáles eran ruido, y qué flujo tenía que seguir la información para que el sistema fuera útil de verdad. Lo que no sabía era cómo traducir eso a tablas, relaciones y queries eficientes. Y eso, resultó ser el trabajo más importante de todo el proyecto.

#Primero, entender qué datos realmente importan

Antes de abrir Supabase, hice algo que cualquier ingeniero industrial haría de forma instintiva: fui a la fuente del problema. Los clientes nos enviaban pre-alertas en Excel. Cada uno tenía su propio formato — columnas distintas, nombres distintos, órdenes distintos. Pero nosotros trabajábamos con un estándar de datos. Así que lo primero fue identificar cuál era ese estándar.

Tener claro ese estándar antes de diseñar la primera tabla fue la decisión más importante de todo el proyecto. No empecé por la tecnología — empecé por el dato. Y el dato lo conocía porque vivía la operación todos los días.

#El diseño que no fue un rediseño, sino una evolución

Rediseñé las tablas tres o cuatro veces antes de que se sintieran bien. Pero no fueron rediseños traumáticos — fueron evoluciones. Conforme avanzaba módulo a módulo, entendía mejor las relaciones que necesitaba y agregaba columnas que hacían la información más coherente.

Esto lo aprendí en el máster de análisis de datos: pensar en bases de datos relacionales no es solo definir tablas — es diseñar el flujo de información. Cómo se conecta una entidad con otra, cómo evitar duplicar datos, cómo garantizar que si algo cambia en un lugar, el cambio se propague correctamente al resto.

La diferencia entre una base de datos bien diseñada y una mal diseñada no siempre se ve en el día uno. Se ve cuando el sistema crece, cuando aparecen casos que no anticipaste, cuando alguien hace algo que no esperabas y el sistema tiene que responder con coherencia.

Por eso fui despacio. Módulo a módulo. Entendiendo bien lo que hacía antes de avanzar al siguiente. No tuve que rehacer nada desde cero — tuve mejoras, no reingeniería.

#La decisión que un desarrollador convencional no habría tomado

Hay una funcionalidad en el sistema que nació directamente de conocer la operación: la desconsolidación de carga.

En logística, a veces un paquete que llega como una unidad necesita dividirse en varios paquetes para enviarse a distintos destinos. La forma estándar que había visto en otros ERPs era simple: marcas el paquete como desconsolidado y creas los nuevos paquetes manualmente. Técnicamente funciona. Operativamente, pierdes la trazabilidad.

En logística, saber de dónde viene cada paquete no es un detalle — es un requisito.

Así que diseñé la herramienta de otra manera: cuando desconsolidás un ticket, el sistema lo marca como "reempacado" y crea los tickets hijos vinculados al padre. La relación padre-hijo queda registrada en la base de datos. Podés ver en cualquier momento de dónde vino cada paquete, qué se hizo con él y hacia dónde fue.

Un desarrollador que no conoce logística habría implementado la versión simple — la que vio en el ERP de referencia — porque técnicamente resuelve el problema. Yo implementé la versión con trazabilidad completa porque sabía exactamente por qué esa trazabilidad importaba.

#Los errores silenciosos — y cómo aprendí a buscarlos

Fue en producción donde aprendí que existían los errores silenciosos. El sistema funcionaba. No había crashes, no había datos corruptos, no había nada que rompiera el flujo. Pero algo no se veía bien.

Una pre-alerta marcada como recibida de forma incompleta aparecía en dos módulos al mismo tiempo: en Pre-alertas y en Bodega. Era correcto que estuviera en los dos — una recepción incompleta necesita seguimiento en ambos lados. El problema era que no había ninguna indicación visual de que estaba incompleta. Sin un badge, sin un color, sin ninguna señal — simplemente aparecía igual que cualquier otra pre-alerta. Y eso generaba confusión.

Funcionaba. Pero no se entendía.

Ese es el error silencioso: no rompe nada, no genera una alerta, no aparece en ningún log. Pero crea ambigüedad. Y la ambigüedad en un sistema operativo es peligrosa, porque las personas toman decisiones basadas en lo que ven — y si lo que ven no es claro, las decisiones tampoco lo son.

La solución fue simple: un badge que indicara "Recepción incompleta" en ambos módulos. Pero encontrar el problema requirió algo que no está en ningún tutorial: usar el sistema con ojos críticos, como alguien que no sabe qué está mirando.

Desde entonces, esa es mi prueba para cada módulo nuevo: ¿lo entendería alguien sin contexto? ¿O requiere que yo esté ahí para explicarlo? Si requiere explicación, el diseño no está terminado.

#Lo que aprendí