/write-query - Écrire du SQL Optimisé

Si tu vois des placeholders non familiers ou si tu dois vérifier quels connecteurs sont actifs, consulte CONNECTORS.md.

Écrire une requête SQL à partir d'une description en langage naturel, optimisée pour ton dialecte SQL spécifique et respectant les bonnes pratiques.

Utilisation

/write-query <description de les données dont tu as besoin>

Flux de travail

1. Comprendre la demande

Analyser la description de l'utilisateur pour identifier :

• Colonnes en sortie : Quels champs le résultat doit-il inclure ?
• Filtres : Quelles conditions limitent les données (plages horaires, segments, statuts) ?
• Agrégations : Y a-t-il des opérations GROUP BY, des comptages, des sommes, des moyennes ?
• Jointures : Faut-il combiner plusieurs tables ?
• Tri : Comment les résultats doivent-ils être ordonnés ?
• Limites : Y a-t-il une exigence top-N ou d'échantillonnage ?

2. Déterminer le dialecte SQL

Si le dialecte SQL de l'utilisateur n'est pas déjà connu, demander lequel il utilise :

• PostgreSQL (incluant Aurora, RDS, Supabase, Neon)
• Snowflake
• BigQuery (Google Cloud)
• Redshift (Amazon)
• Databricks SQL
• MySQL (incluant Aurora MySQL, PlanetScale)
• SQL Server (Microsoft)
• DuckDB
• SQLite
• Autre (demander les détails)

Se souvenir du dialecte pour les futures requêtes dans la même session.

3. Découvrir le schéma (si un warehouse est connecté)

Si un serveur MCP d'entrepôt de données est connecté :

1. Chercher les tables pertinentes en fonction de la description de l'utilisateur
2. Inspecter les noms de colonnes, types et relations
3. Vérifier les clés de partitionnement ou de clustering qui affectent les performances
4. Chercher des vues pré-construites ou matérialisées qui pourraient simplifier la requête

4. Écrire la requête

Respecter ces bonnes pratiques :

Structure :

• Utiliser des CTE (clauses WITH) pour la lisibilité quand les requêtes ont plusieurs étapes logiques
• Une CTE par transformation logique ou source de données
• Nommer les CTE de manière descriptive (ex. daily_signups, active_users, revenue_by_product)

Performance :

• Ne jamais utiliser SELECT * dans les requêtes de production -- spécifier uniquement les colonnes nécessaires
• Filtrer tôt (placer les clauses WHERE aussi près que possible des tables de base)
• Utiliser les filtres de partition quand disponibles (notamment les partitions de date)
• Préférer EXISTS à IN pour les sous-requêtes avec de grands ensembles de résultats
• Utiliser les types de JOIN appropriés (ne pas utiliser LEFT JOIN quand INNER JOIN convient)
• Éviter les sous-requêtes corrélées quand une JOIN ou une fonction de fenêtre fonctionne
• Faire attention aux jointures explosives (plusieurs-à-plusieurs)

Lisibilité :

• Ajouter des commentaires expliquant le « pourquoi » pour la logique non évidente
• Utiliser une indentation et un formatage cohérents
• Aliaser les tables avec des noms courts significatifs (pas juste a, b, c)
• Placer chaque clause majeure sur sa propre ligne

Optimisations spécifiques au dialecte :

• Appliquer la syntaxe et les fonctions spécifiques au dialecte (voir la skill sql-queries pour les détails)
• Utiliser les fonctions de date, les fonctions de chaîne et la syntaxe de fenêtre appropriées au dialecte
• Noter les fonctionnalités de performance spécifiques au dialecte (ex. clustering Snowflake, partitionnement BigQuery)

5. Présenter la requête

Fournir :

1. La requête complète dans un bloc de code SQL avec coloration syntaxique
2. Brève explication de ce que chaque CTE ou section fait
3. Notes de performance si pertinent (coût attendu, utilisation de partition, goulots d'étranglement potentiels)
4. Suggestions de modification -- comment l'ajuster pour les variations courantes (plage de temps différente, granularité différente, filtres supplémentaires)

6. Proposer d'exécuter

Si un entrepôt de données est connecté, proposer d'exécuter la requête et d'analyser les résultats. Si l'utilisateur veut l'exécuter lui-même, la requête est prête à être copiée-collée.

Exemples

Agrégation simple :

/write-query Nombre de commandes par statut pour les 30 derniers jours

Analyse complexe :

/write-query Analyse de rétention de cohorte -- grouper les utilisateurs par mois d'inscription, puis afficher le pourcentage toujours actifs (ayant eu au moins un événement) à 1, 3, 6 et 12 mois après l'inscription

Critique pour les performances :

/write-query Nous avons une table d'événements de 500M de lignes partitionnée par date. Trouver les 100 meilleurs utilisateurs par nombre d'événements au cours des 7 derniers jours avec leur type d'événement le plus récent.

Conseils

• Mentionner ton dialecte SQL d'emblée pour obtenir la bonne syntaxe immédiatement
• Si tu connais les noms des tables, les inclure -- sinon Claude t'aidera à les trouver
• Spécifier si tu as besoin que la requête soit idempotente (sûre à réexécuter) ou ponctuelle
• Pour les requêtes récurrentes, mentionner si elle doit être paramétrée pour les plages de date