Diseña el esquema de base de datos relacional con las relaciones correctas, las claves foráneas necesarias y los índices que hacen la diferencia en producción. Con las queries SQL más comunes optimizadas para tu caso de uso.
Cuándo usarlo: Diseño de bases de datos, SQL, PostgreSQL, optimización
Herramienta recomendada: Claude
Eres un Database Architect con experiencia diseñando esquemas para aplicaciones con millones de registros en PostgreSQL y MySQL. Mi caso de uso: - Tipo de aplicación: [e-commerce / SaaS / marketplace / red social / sistema de reservas / otro] - Entidades principales del negocio: [lista las cosas que necesitas almacenar — usuarios, productos, pedidos, etc.] - Volumen estimado de datos: [N registros en la tabla más grande / crecimiento mensual estimado] - Base de datos: [PostgreSQL / MySQL / SQLite / otra] - Problema de diseño específico: [si lo tienes — relaciones N:M complejas / jerarquías / datos multi-tenant / otro] ## Diseño de Base de Datos — [Aplicación] ### 📐 Esquema relacional (DDL completo) ```sql -- [Nombre de la aplicación] — Schema v1.0 -- Tabla de usuarios CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, email VARCHAR(255) NOT NULL UNIQUE, name VARCHAR(255) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); -- [Resto de tablas según las entidades que describiste] -- Con tipos de datos apropiados, NOT NULL donde corresponde, -- defaults razonables y CHECK constraints para integridad -- Claves foráneas con ON DELETE adecuado: -- ON DELETE CASCADE: cuando el hijo no tiene sentido sin el padre -- ON DELETE RESTRICT: cuando debes prevenir la eliminación accidental -- ON DELETE SET NULL: cuando la relación es opcional ``` ### 🔑 Estrategia de índices **Reglas para este esquema:** 1. Primary keys: automáticamente indexadas 2. Foreign keys: indexar siempre para JOINs rápidos 3. Columnas de filtro frecuente: WHERE email, WHERE status, WHERE created_at 4. Índices compuestos: cuándo y en qué orden de columnas ```sql -- Índices necesarios para este esquema CREATE INDEX idx_[tabla]_[columna] ON [tabla]([columna]); -- Con justificación de por qué cada índice ``` ### 🔍 Queries SQL optimizadas para las operaciones más comunes **Query 1 — [La más frecuente en tu aplicación]:** ```sql -- Versión naive (evitar): SELECT * FROM ... -- Versión optimizada: SELECT [solo columnas necesarias] FROM [tabla principal] JOIN ... WHERE ... -- Con EXPLAIN ANALYZE de lo que esperar ``` **Query 2 — Paginación correcta para tablas grandes:** ```sql -- cursor-based pagination (mejor que OFFSET para tablas grandes): SELECT * FROM items WHERE id > :last_seen_id ORDER BY id LIMIT :page_size; ``` **Query 3 — Agregaciones frecuentes:** [Con índices que las aceleran] ### 📊 Decisiones de diseño explicadas **Por qué usar UUID vs. BIGSERIAL:** Cuándo cada opción tiene sentido para tu caso. **Multi-tenant (si aplica):** Row-level security vs. schema-per-tenant vs. database-per-tenant. **Datos blandos (soft delete):** Cuándo usar `deleted_at` y cómo afecta a los índices. ### 🚀 Checklist antes de ir a producción Las 10 cosas que debes verificar en el esquema antes del primer deploy.