Répondre à des questions métier ad hoc sans toucher au SQL
Quand l'utiliser : Vous avez une question sur vos données (« combien d'utilisateurs sont revenus cette semaine ? ») et le tableau de bord BI ne l'a pas.
Prérequis
- Chaîne de connexion
postgres://en lecture seule vers une réplique — La plupart des PG gérées (RDS, Neon, Supabase) vous permettent de créer des identifiants en lecture seule - Accès réseau du lieu d'exécution de Claude à la base de données — VPN ou liste blanche d'IP pour votre machine
Déroulement
-
Demandez à Claude d'inspecter d'abord les tables pertinentesListez toutes les tables dans notre base de données. Pour les tables liées aux utilisateurs, commandes ou sessions, décrivez leurs schémas.✓ Copié→ Aperçu du schéma avant toute requête
-
Posez la question réelleCombien d'utilisateurs se sont inscrits au cours des 30 derniers jours mais n'ont pas encore passé de commande ? Grouper par semaine d'inscription.✓ Copié→ Claude écrit le SQL, l'exécute, retourne le tableau de résultats
-
Vérifiez les réservesY a-t-il des raisons pour lesquelles ce nombre pourrait être trompeur ? Suppressions logiques ? Fuseau horaire dans created_at ? Types d'utilisateurs spécifiques à exclure ?✓ Copié→ Signalement honnête des particularités des données
Résultat : Une réponse défendable à une question métier avec le SQL, le résultat et les réserves — en 2 minutes au lieu d'attendre 2 jours l'équipe données.
Pièges
- Claude écrit une requête qui analyse votre plus grande table sans limites — Définissez
statement_timeout = '30s'sur la connexion, et ajoutez « toujours inclure LIMIT 1000 par défaut » à votre prompt système - Compter les « utilisateurs » dépend de ce qui compte comme un utilisateur (supprimé ? bot ? test ?) — Dites à Claude vos conventions à l'avance : « exclure les lignes où deleted_at IS NOT NULL » etc.