Diseñando el Modelo de Datos de un SaaS (Y Los Errores Que Me Estoy Encontrando) - Episodio 2

Hoy toca meterme de lleno en el modelo de datos, esa parte fundamental de cualquier aplicación que puede hacer que todo funcione como la seda… o que todo se convierta en un infierno de datos desorganizados y consultas lentas.

Creando el Modelo de Datos Desde Cero. 📅Diario de un SaaS.

Lo que parecía una tarea sencilla se está convirtiendo en un laberinto de decisiones, errores y ajustes constantes. Y aunque estoy avanzando, he tenido que replantearme muchas cosas en el camino.

Si estás pensando en diseñar una base de datos para un SaaS, quédate, porque voy a contarte todos los problemas que me estoy encontrando en tiempo real y cómo los estoy resolviendo.

💡 Primeras Dudas: ¿Qué Datos Son Realmente Necesarios?

Antes de ponerme a escribir una sola línea de código, me hice la gran pregunta:

👉 ¿Qué información necesito almacenar para que el SaaS funcione?

Mi primera idea fue definir solo lo esencial:

📌 Usuarios (users) → Para gestionar quién accede a la plataforma.
📌 Piezas (parts) → El catálogo de productos que los usuarios suben.
📌 Marcas (brands) → Para clasificar las piezas por fabricante.

Hasta aquí, todo bien… pero enseguida me di cuenta de varios problemas:

❌ ¿Cómo gestiono diferentes estados de conservación de las piezas? No es lo mismo una pieza nueva que una usada.
❌ ¿Qué pasa si una pieza pertenece a varias categorías?
❌ ¿Cómo hago que las búsquedas sean eficientes sin ralentizar el sistema?
❌ ¿Debería guardar un historial de cambios o simplemente sobrescribir datos?

Conclusión: Mi primer esquema era demasiado básico y no iba a aguantar un SaaS escalable.

---

🚧 Primer Intento: Un Modelo de Datos Demasiado Simple

Para intentar avanzar rápido, decidí crear una base de datos inicial con solo las tablas clave. Me dije:

"Voy a hacerlo simple y luego si hace falta, lo complico más adelante."

Ese fue mi primer error.

Aquí está el primer modelo de datos que diseñé:

• users (Usuarios): ID, email, contraseña, fecha de registro.
• parts (Piezas): ID, título, descripción, precio, usuario que la sube.
• brands (Marcas): ID, nombre de la marca.

📌 ¿El problema? Era demasiado básico. Faltaban muchas cosas:

🔹 No había relación con los modelos de las piezas (no todas las marcas fabrican los mismos modelos).
🔹 No tenía en cuenta los diferentes estados de las piezas.
🔹 Las búsquedas iban a ser lentas porque no había indexación optimizada.

Aquí me di cuenta de que estaba pensando como programador novato y no como alguien que está diseñando un sistema que realmente tiene que funcionar bien.

Y más cuando no puedo ponerme el sombrero de programador / developer cuando no lo soy.

¿Toco algo de código?

Sí, pero la palabra programador me queda muy grande.

Más bien soy un motivado de la vida, un buscador de soluciones y un tipo que le va la marcha y los retos.

---

🔄 Segunda Iteración: Mejorando la Organización

Ok. Toca corregir el rumbo.

Decidí añadir más estructuras que organizan mejor los datos y facilitan las búsquedas:

✔ Tabla pieza_models → Para enlazar piezas con modelos específicos de las piezas en las que estoy basando el SaaS.
✔ Tabla pieza_calibers → Porque cada modelo de pieza puede tener distintos calibres.
✔ Tabla status → Para guardar el estado de conservación de cada pieza (nuevo, usado, etc.).
✔ Tabla locations → Para gestionar la ubicación exacta de cada pieza.

Ahora la estructura empezaba a tener más sentido.

Pero aquí apareció otro problema…

💡 ¿Qué pasa si un usuario quiere modificar una pieza?

Si alguien cambia el estado de conservación de una pieza o actualiza su precio, ¿sobreescribo la información o guardo un historial de cambios?

Si sobreescribo los datos:
✅ Base de datos más limpia.
❌ Se pierde información valiosa (¿qué pasa si alguien quiere ver cambios anteriores?).

Si guardo un historial de cambios:
✅ Transparencia y trazabilidad de modificaciones.
❌ Crece el tamaño de la base de datos (más registros que gestionar).

Aquí decidí que el historial era importante, así que añadí una tabla events para registrar cada cambio.

✔ Cada vez que una pieza cambia de estado, se guarda un evento en events.
✔ Así los usuarios pueden ver el historial de cambios de cualquier pieza.

---

🏗️ Tercera Iteración: Optimizando para Velocidad

Ahora que la estructura de datos tiene más sentido, el siguiente reto es hacer que las consultas sean rápidas.

💡 Problema: Algunas búsquedas pueden ser lentas si no optimizo bien las relaciones entre las tablas.

Solución:
🔹 Indexar campos clave → Como email en users, part_code en parts, brand_id en brands.
🔹 Usar índices Full-Text Search en title y description para hacer las búsquedas más eficientes.
🔹 Evitar consultas innecesarias con JOINs optimizados.

Esto mejorará la velocidad de respuesta cuando los usuarios busquen piezas en el sistema.

---

🛠️ Lecciones Aprendidas Hasta Ahora

🔥 No subestimes la planificación del modelo de datos. Intentar simplificar demasiado al inicio solo lleva a problemas más adelante.

🔥 Piensa en cómo va a escalar el sistema desde el principio. No solo en los datos que necesitas ahora, sino en los que necesitarás cuando haya cientos de usuarios y miles de registros.

🔥 Optimiza las búsquedas desde el inicio. Si una búsqueda tarda más de 3 segundos, la experiencia de usuario se va al carajo.

🔥 Guarda un historial de cambios siempre que sea posible. No sabes cuándo un usuario querrá ver qué pasó con sus datos en el pasado.

---

📅 ¿Qué Sigue en el Desarrollo del SaaS?

Con la base de datos lista, el siguiente paso es conectar el backend con Flask.

📌 En el próximo post veremos cómo:
✅ Autenticar usuarios con JWT.
✅ Crear los primeros endpoints para gestionar el inventario.
✅ Construir el motor de búsqueda optimizado con IA.

---

🚀 Reflexión Final: Construir Bien Desde el Principio Evita Problemas Más Adelante

Diseñar una base de datos parece simple, pero toma más tiempo del que uno cree. Y está bien.

Prefiero invertir tiempo ahora en hacer algo bien estructurado y escalable, en lugar de encontrarme con un desastre más adelante.

💬 ¿Has tenido problemas diseñando bases de datos? Cuéntamelo en los comentarios, seguro que has pasado por algo parecido.

📢 Nos vemos en el próximo post, donde conectaré todo esto con Flask y empezaré a darle vida al SaaS.

Si quieres conocer otros artículos parecidos a Diseñando el Modelo de Datos de un SaaS (Y Los Errores Que Me Estoy Encontrando) - Episodio 2 puedes visitar la categoría Proyecto-IA.