Revision de Esquema de Base de Datos

El Problema

Los errores de diseno de esquema son los bugs mas costosos en software. Un indice faltante causa que una consulta escanee millones de filas. Un foreign key faltante permite registros huerfanos que corrompen reportes. A diferencia del codigo de aplicacion, los cambios de esquema en tablas grandes de produccion requieren planificacion cuidadosa de migracion — no puedes simplemente “arreglarlo despues” sin riesgo de downtime.

El Prompt

Revisa el siguiente esquema de base de datos. Actua como un arquitecto de base de datos evaluando integridad de datos, rendimiento de consultas y seguridad de evolucion.

BASE DE DATOS: [PostgreSQL / MySQL / MongoDB / SQLite]
ESCALA ESPERADA: [ej. 10M filas en ordenes, 500k usuarios]
ESQUEMA:
[pegar CREATE TABLE, esquema Prisma o archivos de migracion]

CONSULTAS COMUNES:
[pegar las consultas mas frecuentes]

Evalua en estas dimensiones:

1. **Normalizacion**
   - El esquema esta en 3NF? Si desnormalizado, esta justificado?
   - Hay columnas duplicadas que se desincronizaran?
   - Las relaciones many-to-many estan modeladas con tablas junction?

2. **Estrategia de Indices**
   - Todos los foreign keys tienen indices?
   - Las columnas WHERE en consultas frecuentes tienen indices apropiados?
   - Hay indices compuestos para lookups multi-columna?

3. **Constraints & Integridad**
   - Los NOT NULL constraints estan donde los datos son requeridos?
   - Los foreign keys estan definidos (no solo por convencion)?
   - Los unique constraints estan donde las reglas de negocio exigen unicidad?

4. **Tipos de Datos**
   - Los tipos de columna estan dimensionados apropiadamente?
   - Los valores monetarios se almacenan como DECIMAL, no FLOAT?
   - Los timestamps usan TIMESTAMPTZ (timezone-aware)?

5. **Eficiencia de Consultas**
   - Las consultas comunes haran full table scans?
   - La forma del esquema implica patrones N+1?

Para cada problema, proporciona:
- **Tabla/Columna**: Lo afectado
- **Severidad**: Riesgo-datos / Rendimiento / Mejora
- **Impacto**: Que se rompe a escala
- **Fix**: Statement DDL o cambio de esquema con notas de migracion

Ejemplo de Salida

## Revision de Esquema: 4 problemas encontrados

### Riesgo de Datos: Foreign Key Faltante
Tabla: order_items.product_id — sin FK constraint a products.id
Fix:
  ALTER TABLE order_items ADD CONSTRAINT fk_order_items_product
  FOREIGN KEY (product_id) REFERENCES products(id) ON DELETE RESTRICT;

### Rendimiento: Indice Faltante en Consulta Frecuente
Tabla: orders — consulta `SELECT * FROM orders WHERE user_id = ? AND status = ?`
Fix: CREATE INDEX idx_orders_user_status ON orders(user_id, status);

Cuando Usar

Ejecutar antes de crear archivos de migracion, al incorporarse a una BD legacy, o durante investigaciones de rendimiento. Particularmente valioso antes de que la BD crezca al punto donde ALTER TABLE se convierte en una operacion de horas.

Tips Pro

• Incluir consultas — la calidad del esquema es irrelevante sin saber como se accede a los datos.
• Especificar escala — consejos de indices para 10,000 filas difieren drasticamente de 10,000,000 filas.
• Pedir scripts de migracion — “Genera SQL de migracion segura para cada fix, usando patrones zero-downtime.”
• Revisar esquemas generados por ORM — ORMs como Prisma toman decisiones que deberias verificar.