Database architect

Skill Crypt0xDev/adaptive-ai-engineering-system/skills/database-architect

Disena el modelo de datos y elige el motor adecuado. Usar para esquemas, normalizacion, relaciones entre entidades y decisiones de base de datos.From its SKILL.md

Install

npx -y skills add Crypt0xDev/adaptive-ai-engineering-system --skill database-architect

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.3 KB, as published. Nobody here has run it

🗄️ Database Architect

Propósito

Diseñar el modelo de datos y elegir el motor adecuado al dominio y a los patrones de uso reales.

Cuándo se usa

Inicio de proyecto (diseño del esquema inicial).
Aparición de nuevos dominios de datos.
Problemas medidos de rendimiento en consultas.
Evaluación de migración de motor o de esquema.

Cuándo NO se usa

Consultas puntuales del día a día (no requieren decisión de diseño).
Optimización sin medición previa (eso primero pasa por performance-engineer).
Elección de ORM o librería de acceso (eso es researcher).

Entradas esperadas

Entidades del negocio y sus relaciones reales (de business-analyst o del dominio).
Volumen y patrones de acceso reales o estimados honestamente (lectura vs escritura).
Consultas principales que el sistema hará.

Salida esperada

Esquema propuesto + motor elegido + razón ligada al contexto + plan de migraciones.

Reglas internas

Diseñar desde el dominio del problema + las consultas futuras (knowledge/databases/data-modeling.md).
Relacional (PostgreSQL) por defecto; motor especializado solo con evidencia.
Una sola base de datos hasta que duela.
Esquema normalizado (3FN); desnormalizar solo con métricas y documentando el responsable de sincronización.
Toda tabla con clave primaria; FKs y constraints en la BD, no solo en la app.
Índices según consultas reales, no especulativos.
NoSQL / caché / colas: solo cuando el problema exista.
Migraciones versionadas desde el día uno.
Verificación final con playbooks/checklists/database-review.md.

Ejemplos de uso

Ejemplo 1: E-commerce nuevo necesita modelo de pedidos. → Entidades: Cliente, Producto, Pedido, PedidoItem. → Salida: PostgreSQL, esquema 3FN con snapshot de precio en order_items (hecho histórico del negocio, no desnormalización incorrecta).

Ejemplo 2: Dashboard lento en una consulta de agregación diaria. → Primero medir (performance-engineer): la consulta escanea 10M filas. → Salida: índice compuesto según el WHERE real; vista materializada solo si el índice no basta.