Veo muchos tutoriales que enseñan a armar tablas relacionales usando INT AUTO_INCREMENT y borrados en cascada. En un proyecto de universidad está bien, pero en un sistema transaccional real (como un e-commerce o una app de delivery), hacer eso destruye la contabilidad o expone tus métricas de ventas a la competencia.
1. El error de los identificadores: INT vs UUID
Si usas INT AUTO_INCREMENT en una tabla de Pedidos, expones métricas de negocio. Si un competidor hace un pedido hoy y su ID es 100, y mañana hace otro y su ID es 150, sabrá exactamente cuántos pedidos procesaste.
Solución: Usa UUID para las transacciones expuestas al cliente.
2. El peligro del ON DELETE CASCADE
Muchos enseñan a usar ON DELETE CASCADE en las claves foráneas. Si borras a un usuario del sistema, el motor SQL borrará en cascada todas sus facturas y pedidos, dejando tu contabilidad descuadrada.
Solución: En tablas transaccionales se debe usar RESTRICT o SET NULL.
Armé una guía técnica profunda sobre cómo estructurar un backend desde cero, manejar precisión financiera con DECIMAL y usar restricciones lógicas para proteger la integridad de los datos sin romper el rendimiento de los índices B-Tree.
Puedes leer la guía completa con todo el código SQL y explicaciones paso a paso en mi blog:
👉 Diseño de Bases de Datos Relacionales y Optimización SQL - LogicBoard.dev
¡Cualquier feedback sobre la arquitectura que proponen en sus trabajos es bienvenido en los comentarios!
Top comments (0)