Prompt de conception de schéma de base de données

Quand l'utiliser

Utilisez ce prompt lorsque vous avez besoin de concevoir un schéma relationnel et souhaitez un point de départ concret plutôt que de simples listes génériques d'entités. Remplacez les détails fictifs par vos propres règles métier validées avant d'utiliser le résultat dans un environnement réel.

Le prompt

## Rôle
Agis en tant qu'architecte de bases de données backend. Fais preuve de jugement professionnel tout en rendant tes décisions techniques compréhensibles pour un ingénieur logiciel de niveau intermédiaire.

## Contexte
KiteFleet exploite un service multi-locataire de location d'équipements. Les clients louent des engins lourds à la journée ou à la semaine. Le système doit assurer le suivi des stocks sur plusieurs dépôts, les réservations multi-articles des clients, les dépôts de garantie ainsi que les inspections de maintenance. Un équipement ne peut pas être loué lorsqu'il fait l'objet d'une inspection active. KiteFleet utilise PostgreSQL 16.

## Objectif
Concevoir un schéma relationnel normalisé qui empêche les doubles réservations, enregistre les transitions d'état des actifs et sépare la facturation client de l'historique des réservations.

## Public cible
Les utilisateurs principaux sont des ingénieurs backend. Rends le livrable immédiatement utilisable pour des scripts de migration, avec un contexte technique suffisant pour justifier le choix des types de données et de l'indexation.

## Exigences
Fournis un DDL PostgreSQL propre ; des définitions de tables avec clés primaires, clés étrangères et contraintes de colonnes ; des types enum pour les états ; des index partiels ou d'unicité pour empêcher les chevauchements de réservations ; ainsi qu'une brève explication de la cardinalité relationnelle pour les entités clés.

## Contraintes
N'introduis pas de microservices externes, de flux d'événements (event streams) ni de bases orientées documents. Travaille exclusivement avec des tables relationnelles dans PostgreSQL. N'invente pas de formules tarifaires ni d'intégrations de passerelles de paiement au-delà des soldes monétaires standards. Énonce clairement toutes les hypothèses de normalisation.

## Ton & style
Sois précis, idiomatique et technique. Privilégie des noms de contraintes explicites, les conventions SQL standard et le snake_case. Inclus de courts commentaires intégrés pour les contraintes non évidentes.

## Format de sortie
Présente d'abord le script DDL PostgreSQL dans un bloc de code dédié. Enchaîne avec un tableau récapitulatif détaillant les relations entre entités. Termine par un tableau justifiant le choix des index et une courte liste de cas limites (edge cases) nécessitant une gestion au niveau applicatif.

## Ce qu'il faut éviter
Évite les types TEXT génériques pour les statuts contraints, l'absence de règles de cascade sur les clés étrangères, les mécanismes de suppression réversible (soft-delete) sans prise en compte des index, et les clés UUID génériques sans justification de performance.

## Critères de succès
Un ingénieur doit pouvoir exécuter le DDL sans erreur de syntaxe, comprendre comment les réservations conflictuelles sont bloquées et vérifier que les états de maintenance empêchent la planification d'une location.

## Questions de clarification
Pose jusqu'à trois questions ciblées uniquement si l'absence de limites claires dans le schéma venait à modifier les formes normales des tables. Sinon, poursuis avec le scénario, documente tes hypothèses et souligne les compromis à prévoir pour la production.

Pourquoi ça fonctionne

• Le scénario définit une logique métier explicite (dépôts, chevauchements de locations, blocages pour maintenance) au lieu d'un modèle CRUD abstrait.
• Les exigences imposent un DDL prêt pour la production et une protection contre les accès concurrents, plutôt que de simples diagrammes d'entités.
• Les contraintes maintiennent la conception centrée sur l'intégrité transactionnelle essentielle sans architecture distribuée prématurée.
• Les critères de succès garantissent un code exécutable qui applique directement les règles métier du scénario.

Adaptez-le

Créez une version sur mesure avec PromptDeck en remplaçant le scénario fictif par votre propre contexte, votre public et vos contraintes. Conservez les étapes de vérification pour que le résultat final reflète précisément ce que vous maîtrisez.