Prompt para el diseño de esquemas de bases de datos

Cuándo utilizarlo

Utilice este recurso cuando necesite diseñar un esquema relacional y busque un punto de partida concreto en lugar de listas genéricas de entidades. Sustituya los detalles ficticios por sus propias reglas de negocio confirmadas antes de aplicar el resultado en un entorno real.

El prompt

## Rol
Actúa como un arquitecto de bases de datos backend. Aplica tu criterio profesional manteniendo tus decisiones técnicas comprensibles para un ingeniero de software de nivel intermedio.

## Contexto
KiteFleet opera un servicio multiinquilino (multi-tenant) de alquiler de maquinaria. Los clientes alquilan maquinaria pesada por días o semanas. El sistema debe rastrear el inventario en múltiples depósitos, reservas de clientes con varios artículos, depósitos de garantía e inspecciones de mantenimiento. La maquinaria no se puede alquilar mientras esté bajo una inspección activa. KiteFleet utiliza PostgreSQL 16.

## Objetivo
Diseñar un esquema relacional normalizado que evite reservas duplicadas (double-booking), registre las transiciones de estado de los activos y separe la facturación de los clientes del historial de reservas.

## Audiencia
Los usuarios principales son ingenieros backend. Haz que el entregable sea utilizable de inmediato para scripts de migración, con suficiente contexto técnico para justificar los tipos de datos y las decisiones de indexación.

## Requisitos
Proporciona DDL limpio para PostgreSQL; definiciones de tablas con claves primarias, claves foráneas y restricciones de columna; tipos enum para los estados; índices parciales o únicos para evitar solapamientos en las reservas; y una breve explicación de la cardinalidad relacional para las entidades principales.

## Restricciones
No introduzcas microservicios externos, flujos de eventos ni almacenes de documentos. Trabaja estrictamente con tablas relacionales en PostgreSQL. No inventes fórmulas de precios ni integraciones con pasarelas de pago más allá de balances monetarios estándar. Declara claramente todas las suposiciones de normalización.

## Tono y estilo
Sé preciso, idiomático y técnico. Da preferencia a nombres de restricciones explícitos, convenciones estándar de SQL y nomenclatura en snake_case. Incluye comentarios breves en el código para restricciones que no sean obvias.

## Formato de salida
Presenta primero el script DDL de PostgreSQL en un bloque de código dedicado. A continuación, incluye un resumen de tablas que detalle las relaciones entre entidades. Finaliza con una tabla de justificación de índices y una breve lista de casos extremos (edge cases) que requieran validación a nivel de aplicación.

## Qué evitar
Evita tipos TEXT genéricos para estados delimitados, reglas de cascada ausentes en claves foráneas, mecanismos de borrado lógico (soft-delete) sin consideraciones de indexación y claves UUID genéricas sin justificación de rendimiento.

## Criterios de éxito
Un ingeniero debe poder ejecutar el DDL sin errores de sintaxis, comprender cómo se bloquean las reservas solapadas y verificar que los estados de mantenimiento impidan la programación de alquileres.

## Preguntas de aclaración
Haz hasta tres preguntas específicas solo si la falta de límites en el esquema alterase las formas normales de las tablas. De lo contrario, continúa con el escenario planteado, documenta las suposiciones y destaca las compensaciones prácticas de cara a producción.

Por qué funciona

• El escenario define una lógica de dominio explícita (depósitos, alquileres solapados, bloqueos por mantenimiento) en lugar de un modelo CRUD abstracto.
• Los requisitos exigen DDL listo para producción y protección de concurrencia, en vez de simples diagramas de entidades.
• Las restricciones mantienen el diseño enfocado en la integridad transaccional central, evitando arquitecturas distribuidas prematuras.
• Los criterios de éxito garantizan código ejecutable que aplica directamente las reglas de negocio del escenario.

Adáptelo a sus necesidades

Cree una versión personalizada con PromptDeck sustituyendo el escenario ficticio por su propio contexto, audiencia y restricciones. Conserve los pasos de verificación para que el resultado final refleje fielmente lo que usted realmente conoce.