Base de datos: el modelado que sostiene (o derrumba) el producto
La base de datos suele ser la parte más permanente de un sistema. Las interfaces cambian, los lenguajes se sustituyen, los servicios se reescriben — los datos, y la forma en que fueron modelados, permanecen. Por eso las decisiones de modelado merecen el mismo cuidado que normalmente se reserva a la arquitectura general.
Modelar es describir reglas del negocio, no diseñar pantallas
Un buen modelo expresa lo que existe en el dominio y qué relaciones son obligatorias. Cuando el modelado parte de la pantalla, el resultado es un conjunto de tablas que refleja la interfaz del primer mes y resiste mal la segunda funcionalidad.
Las claves, restricciones de unicidad e integridad referencial no son burocracia: son reglas de negocio escritas en el lugar donde ninguna parte de la aplicación puede saltárselas por error.
- Las restricciones en la base de datos garantizan invariantes incluso con múltiples servicios escribiendo.
- Normalizar primero; desnormalizar después, con medición y motivo explícito.
- Los campos de estado deben tener un dominio cerrado, no texto libre.
Los índices resuelven la lectura y cobran en la escritura
Un índice es un intercambio: acelera consultas específicas y añade costo a cada escritura. La elección debe nacer de las consultas reales del producto, observadas en producción, y no de suposiciones hechas antes del primer usuario.
Analizar el plan de ejecución de una consulta lenta suele revelar más en diez minutos que una semana de optimización por intuición.
SQL, NoSQL y la pregunta correcta
La pregunta útil no es qué tecnología es mejor, sino qué garantías exige el dominio. Donde hay dinero, inventario, contratos o cualquier invariante que no puede romperse, las transacciones y la consistencia fuerte valen más que la flexibilidad de esquema.
Las bases de datos relacionales modernas absorben documentos, búsquedas y series temporales con competencia. Introducir una segunda tecnología debe ser respuesta a un límite medido, no a una preferencia estética.
Migraciones y evolución sin detener el producto
El esquema cambia. Lo que separa a un equipo tranquilo de uno en pánico es el proceso: migraciones versionadas, aplicadas en etapas compatibles con la versión anterior del código, siempre reversibles y probadas antes de tocar producción.
En resumen
El modelo de datos es una decisión de largo plazo: escribe las reglas del dominio en la base de datos, mide antes de optimizar y trata la migración como parte normal del ciclo de entrega.
Casos de uso
SaaS multiempresa
Aislamiento por organización con clave en todas las tablas y políticas de acceso aplicadas en la propia base de datos.
Reportes pesados
Separación entre carga transaccional y analítica, con vistas materializadas actualizadas en ventana controlada.
Cola de trabajo
Estados explícitos, bloqueo por fila e idempotencia para evitar procesamiento duplicado.
Errores comunes
- Guardar valores monetarios en punto flotante.
- Usar texto libre para estados y luego depender de comparación de strings.
- Crear un índice para cada columna, degradando la escritura sin ganancia real de lectura.
- Hacer una migración destructiva sin plan de reversión.
Buenas prácticas
- Tipos correctos desde el principio, incluyendo zona horaria en las fechas.
- Restricciones de integridad en la base de datos, no solo en la aplicación.
- Consultas observadas con métrica de tiempo y frecuencia.
- Backup probado mediante restauración real, en intervalo definido.
Libros recomendados
Designing Data-Intensive Applications — Martin Kleppmann
Explica con rigor y claridad los trade-offs de consistencia, replicación y particionamiento.
SQL Performance Explained — Markus Winand
Vuelve concreto el efecto de los índices y los planes de ejecución en el rendimiento.
Database Design for Mere Mortals — Michael J. Hernandez
Base sólida de modelado para quien está empezando.
Para profundizar
Preguntas frecuentes
- ¿Debo elegir SQL o NoSQL?
- Empieza por las garantías que exige el dominio. Si hay invariantes críticas y relaciones ricas, lo relacional suele ser la opción más segura.
- ¿Cuándo crear un índice?
- Cuando una consulta frecuente y lenta está comprobada por medición, y la ganancia de lectura compensa el costo de escritura.
- ¿Normalizar siempre?
- Normaliza por defecto. Desnormaliza puntualmente, con datos medidos y control explícito de actualización.
- ¿Cómo evitar pérdida de datos en una migración?
- Migración en etapas compatibles, ejecución ensayada en copia de producción, reversión lista y backup verificado antes.
Referencias
- Martin Kleppmann — garantías de consistencia en sistemas distribuidos
- Markus Winand — uso de índices y lectura de planes de ejecución
- Documentación de PostgreSQL — transacciones y aislamiento
Contenido original del equipo de i9 Conecty. Los conceptos clásicos se explican con palabras propias y se acreditan a sus autores.