postgresql-table-design
Concevoir des schémas PostgreSQL avec des conseils d'expert
La conception de schémas PostgreSQL nécessite une connaissance des types de données, des stratégies d'indexation, des contraintes et des modèles de performance. Cette compétence fournit des conseils complets sur les meilleures pratiques spécifiques à PostgreSQL, les fonctionnalités avancées et les pièges courants pour vous aider à créer des schémas de base de données efficaces et maintenables.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "postgresql-table-design". Comment dois-je stocker des valeurs monétaires dans PostgreSQL ?
Résultat attendu:
Utilisez NUMERIC(p,s) pour les valeurs monétaires, jamais les types float. Par exemple : amount NUMERIC(10,2) pour une devise avec deux décimales. Cela fournit une arithmétique décimale exacte sans problèmes de précision en virgule flottante. Évitez le type money obsolète.
Utilisation de "postgresql-table-design". Quelle est la différence entre BIGINT GENERATED ALWAYS AS IDENTITY et UUID pour les clés primaires ?
Résultat attendu:
- BIGINT GENERATED ALWAYS AS IDENTITY : ID entiers séquentiels. Préféré pour la plupart des cas d'usage. Avantages : stockage plus petit, indexation plus rapide, meilleure localité. À utiliser lorsque l'unicité globale entre systèmes n'est pas requise.
- UUID : Identifiants globalement uniques. À utiliser lorsque : fusion de données provenant de plusieurs bases de données, fédération de systèmes ou besoin d'ID non séquentiels opaques. Générez avec uuidv7() sur PostgreSQL 18+ ou gen_random_uuid() sur les versions antérieures.
Utilisation de "postgresql-table-design". Dois-je ajouter des index sur les colonnes de clés étrangères ?
Résultat attendu:
Oui, ajoutez toujours des index explicites sur les colonnes de clés étrangères. PostgreSQL n'indexe pas automatiquement les colonnes FK contrairement à certaines bases de données. Cela accélère les jointures et évite les problèmes de verrouillage lors des suppressions ou mises à jour de la table parente. Exemple : CREATE INDEX ON orders (user_id) pour la clé étrangère user_id.
Audit de sécurité
SûrThis 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.
Score de qualité
Ce que vous pouvez construire
Concevoir un nouveau schéma de base de données
Obtenez des conseils sur la structure des tables, les types de données, les contraintes et les stratégies d'indexation lors de la conception d'une nouvelle base de données PostgreSQL pour une application.
Optimiser les performances d'un schéma existant
Découvrez les stratégies d'indexation, les options de partitionnement et les modèles de performance pour améliorer les performances des requêtes et réduire le gonflement de la base de données.
Réviser les décisions de conception de schéma
Validez les choix de types de données, l'utilisation des contraintes et les décisions de normalisation par rapport aux meilleures pratiques PostgreSQL avant l'implémentation.
Essayez ces prompts
J'ai besoin de créer une table users avec email, name et timestamps. Quel est le schéma PostgreSQL recommandé ?
Je stocke des prix de produits, des adresses IP et des préférences utilisateur. Quels types de données PostgreSQL dois-je utiliser ?
Ma table orders a des requêtes filtrant par user_id, status et created_at. Quels index dois-je créer ?
Je dois stocker des millions de lectures de capteurs par jour avec des requêtes filtrant par appareil et plage de temps. Comment dois-je concevoir le schéma et le partitionnement ?
Bonnes pratiques
- Commencez avec des schémas normalisés à la troisième forme normale et ne dénormalisez que lorsque vous avez mesuré des problèmes de performance avec des requêtes spécifiques à forte valeur
- Utilisez TIMESTAMPTZ pour toutes les colonnes timestamp, TEXT pour les chaînes, NUMERIC pour l'argent et BIGINT GENERATED ALWAYS AS IDENTITY pour les clés primaires sauf si vous avez besoin d'UUID
- Créez des index pour les colonnes utilisées dans les clauses WHERE, les conditions JOIN et les clauses ORDER BY, et ajoutez toujours des index explicites sur les colonnes de clés étrangères
Éviter
- N'utilisez pas les types de données VARCHAR(n) ou CHAR(n) ; utilisez TEXT avec des contraintes CHECK pour les limites de longueur si nécessaire
- N'utilisez pas TIMESTAMP without time zone, le type money ou SERIAL ; utilisez plutôt TIMESTAMPTZ, NUMERIC et GENERATED ALWAYS AS IDENTITY
- Ne dénormalisez pas les données prématurément avant de mesurer les problèmes de performance réels ; la dénormalisation prématurée crée une charge de maintenance sans bénéfices prouvés