postgresql-table-design
Diseña esquemas de PostgreSQL con orientación experta
El diseño de esquemas de PostgreSQL requiere conocimiento de tipos de datos, estrategias de indexación, restricciones y patrones de rendimiento. Esta habilidad proporciona orientación integral sobre mejores prácticas específicas de PostgreSQL, características avanzadas y errores comunes para ayudarte a construir esquemas de base de datos eficientes y mantenibles.
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "postgresql-table-design". ¿Cómo debería almacenar valores monetarios en PostgreSQL?
Resultado esperado:
Usa NUMERIC(p,s) para valores monetarios, nunca tipos float. Por ejemplo: amount NUMERIC(10,2) para moneda con dos decimales. Esto proporciona aritmética decimal exacta sin problemas de precisión de punto flotante. Evita el tipo money obsoleto.
Usando "postgresql-table-design". ¿Cuál es la diferencia entre BIGINT GENERATED ALWAYS AS IDENTITY y UUID para claves primarias?
Resultado esperado:
- BIGINT GENERATED ALWAYS AS IDENTITY: IDs enteros secuenciales. Preferidos para la mayoría de los casos de uso. Beneficios: menor almacenamiento, indexación más rápida, mejor localidad. Usa cuando no se requiere unicidad global entre sistemas.
- UUID: Identificadores únicos globales. Usa cuando: se fusionan datos de múltiples bases de datos, se federan sistemas o se requieren IDs opacos no secuenciales. Genera con uuidv7() en PostgreSQL 18+ o gen_random_uuid() en versiones anteriores.
Usando "postgresql-table-design". ¿Debería agregar índices en columnas de clave foránea?
Resultado esperado:
Sí, siempre agrega índices explícitos en columnas de clave foránea. PostgreSQL no indexa automáticamente columnas FK a diferencia de algunas bases de datos. Esto acelera las uniones y previene problemas de bloqueo durante eliminaciones o actualizaciones de la tabla padre. Ejemplo: CREATE INDEX ON orders (user_id) para la clave foránea user_id.
Auditoría de seguridad
SeguroThis skill is a documentation-only resource providing PostgreSQL schema design guidance. All 237 static findings are false positives triggered by SQL examples and technical terminology in markdown code blocks. The skill contains no executable code, network calls, or file system access. Safe for publication.
Puntuación de calidad
Lo que puedes crear
Diseñar un nuevo esquema de base de datos
Obtén orientación sobre estructura de tablas, tipos de datos, restricciones y estrategias de indexación al diseñar una nueva base de datos PostgreSQL para una aplicación.
Optimizar el rendimiento de un esquema existente
Aprende sobre estrategias de indexación, opciones de particionamiento y patrones de rendimiento para mejorar el rendimiento de las consultas y reducir la saturación de la base de datos.
Revisar decisiones de diseño de esquema
Valida las elecciones de tipos de datos, uso de restricciones y decisiones de normalización contra las mejores prácticas de PostgreSQL antes de la implementación.
Prueba estos prompts
Necesito crear una tabla de usuarios con email, nombre y marcas de tiempo. ¿Cuál es el esquema de PostgreSQL recomendado?
Estoy almacenando precios de productos, direcciones IP y preferencias de usuario. ¿Qué tipos de datos de PostgreSQL debería usar?
Mi tabla de pedidos tiene consultas que filtran por user_id, status y created_at. ¿Qué índices debería crear?
Necesito almacenar millones de lecturas de sensores por día con consultas que filtran por dispositivo y rango de tiempo. ¿Cómo debería diseñar el esquema y el particionamiento?
Mejores prácticas
- Comienza con esquemas normalizados a tercera forma normal y solo desnormaliza cuando hayas medido problemas de rendimiento con consultas específicas de alto valor
- Usa TIMESTAMPTZ para todas las columnas de marca de tiempo, TEXT para cadenas, NUMERIC para dinero y BIGINT GENERATED ALWAYS AS IDENTITY para claves primarias a menos que necesites UUIDs
- Crea índices para columnas usadas en cláusulas WHERE, condiciones JOIN y cláusulas ORDER BY, y siempre agrega índices explícitos en columnas de clave foránea
Evitar
- No uses tipos de datos VARCHAR(n) o CHAR(n); usa TEXT con restricciones CHECK para límites de longitud si es necesario
- No uses TIMESTAMP sin zona horaria, el tipo money o SERIAL; usa TIMESTAMPTZ, NUMERIC y GENERATED ALWAYS AS IDENTITY en su lugar
- No desnormalices datos prematuramente antes de medir problemas de rendimiento reales; la desnormalización prematura crea carga de mantenimiento sin beneficios comprobados