SQL-маître : comment obtenir une requête SQL précise à partir d'une description et d'un schéma

Que fait exactement SQL-maître

L'outil accepte deux champs textuels : « Votre texte ou idée » et « SGBD et schéma de table ». Dans le premier champ, vous décrivez la tâche en mots ordinaires, et dans le second, vous indiquez le dialecte SGBD et la structure des tables avec les types de champs. Après avoir appuyé sur le bouton de génération, vous obtenez un résultat unique dans une panneau séparé, que vous pouvez copier ou télécharger sous forme de fichier texte TXT classique.

Limite clé : SQL-maître ne se connecte pas à votre base de données, n'exécute pas la requête et ne vérifie pas l'existence des tables ou des champs. Il construit simplement du texte de requête en fonction de ce que vous avez écrit et peut ajouter ses propres hypothèses. Par conséquent, tous les noms de tables et de colonnes doivent être indiqués exactement -- l'outil ne pourra pas corriger une faute de frappe, car il ne voit pas le schéma réel.

Le champ de description de la tâche accepte jusqu'à 8000 caractères, et le champ schéma -- jusqu'à 1000 caractères. Cela suffit pour les requêtes typiques, mais pas pour la description d'un schéma très vaste. Si vous avez beaucoup de tables, ne lister que celles qui participent à la tâche, et indiquez obligatoirement les relations entre elles.

Entrée : « Affichez l'ID de la commande et le total pour les commandes de plus de 500, triées par ordre décroissant du total. » Schéma : « PostgreSQL, orders(id integer, total numeric) ».

Comment formuler la description de la tâche

Plus la description est précise, plus le résultat est utile. Au lieu de « montrez les commandes », écrivez quels champs exactement vous voulez dans le résultat, quelles conditions de filtrage appliquer, si vous avez besoin de regroupement, de tri ou de limitation du nombre de lignes. Par exemple : « Affichez customer_id et le total des commandes pour chaque client, uniquement pour les clients avec un total supérieur à 1000, triez par ordre décroissant du total. »

Si la tâche permet différentes interprétations, indiquez la version préférée. Par exemple, la phrase « affichez les clients et leurs commandes » ne dit pas si l'on doit inclure les clients sans commandes. Ajoutez « en incluant les clients sans commandes » -- et l'outil construira plus probablement un LEFT JOIN plutôt qu'un INNER JOIN.

Ne mélangez pas plusieurs tâches indépendantes dans une même description : il vaut mieux générer des requêtes séparées et les combiner manuellement. Ainsi, il est plus facile de vérifier chaque fragment et d'éviter les erreurs dans les conditions de jointure.

Entrée : « Affichez les noms des clients et le total de leurs commandes, en incluant les clients sans commandes. » Schéma : « MySQL, customers(id int, name varchar(100)), orders(id int, customer_id int, total decimal(10,2)) ».

Comment décrire la SGBD et le schéma de tables

Dans le deuxième champ, indiquez obligatoirement le dialecte : PostgreSQL, MySQL, SQLite, Oracle, SQL Server, etc. La syntaxe diffère : par exemple, la limitation du nombre de lignes s'effectue via LIMIT dans PostgreSQL et MySQL, via ROWNUM dans Oracle, via TOP dans SQL Server. Si le dialecte n'est pas indiqué, l'outil peut choisir une syntaxe qui ne convient pas à votre SGBD.

Listez les tables au format « nom_champ type_de_champ ». Indiquez les types de données : integer, numeric, varchar, text, date. Cela aide l'outil à construire correctement les comparaisons et les agrégats. Si entre les tables il y a une relation, décrivez-la en mots : « orders.customer_id fait référence à customers.id ».

Si dans le schéma il y a des champs avec des NULL potentiels, mentionnez-le. L'outil peut supposer que les valeurs ne sont pas vides, et ne pas ajouter de traitement NULL. Indiquer explicitement « le champ total peut être NULL » réduit le risque de résultat incorrect.

Schéma : « SQLite, customers(id integer, name text), orders(id integer, customer_id integer, total real), orders.customer_id fait référence à customers.id, total peut être NULL ».

Exemple : agrégation avec regroupement

Supposons que vous deviez calculer le total des commandes par client. Dans la description, indiquez : « Trouvez le total des commandes pour chaque customer_id. » Schéma : « PostgreSQL, orders(id integer, customer_id integer, total numeric) ». L'outil générera une requête avec GROUP BY sur customer_id et la fonction d'agrégation SUM.

Vérifiez que tous les champs non agrégés dans SELECT figurent dans GROUP BY. Si l'outil ajoute l'hypothèse que total ne contient pas de NULL, le résultat SUM peut différer de l'attendu : les NULL sont ignorés, mais en l'absence de commandes pour un client, la ligne peut tout simplement ne pas apparaître. Si nécessaire, ajoutez manuellement COALESCE ou LEFT JOIN.

Exécutez la requête sur un jeu de données de test et comparez avec le calcul manuel. Souvenez-vous que SQL-maître n'exécute pas la requête, donc les erreurs de syntaxe ne seront visibles que lors de l'exécution dans votre SGBD.

Entrée : « Trouvez le total des commandes pour chaque customer_id. » Schéma : « PostgreSQL, orders(id integer, customer_id integer, total numeric) ». Résultat possible : SELECT customer_id, SUM(total) AS total_sum FROM orders GROUP BY customer_id;

Exemple : jointure de tables

Supposons qu'il y a deux tables : customers(id, name) et orders(id, customer_id, total). Tâche : « Affichez le nom du client et le total de ses commandes. » Dans le schéma, indiquez les deux tables et la relation entre elles. L'outil construira une JOIN sur customer_id.

Le type de jointure dépend de la formulation. Si vous voulez inclure les clients sans commandes, ajoutez cela à la description -- alors on s'attend à un LEFT JOIN. Si vous ne voulez que les clients avec des commandes, l'INNER JOIN convient. L'outil ne connaît pas vos règles métier, donc formulez le exigence explicitement.

Après génération, vérifiez la condition de jointure : les noms de champs doivent correspondre au schéma. Assurez-vous que le nombre de lignes correspond aux attentes : avec INNER JOIN, les clients sans commandes disparaissent, avec LEFT JOIN, ils apparaissent avec une valeur NULL dans les champs de commandes.

Entrée : « Affichez le nom du client et le total de ses commandes. » Schéma : « MySQL, customers(id int, name varchar(100)), orders(id int, customer_id int, total decimal(10,2)) ». Résultat possible : SELECT c.name, o.total FROM customers c JOIN orders o ON c.id = o.customer_id;

Exemple : sous-requête et filtrage

Tâche : trouver les clients qui ont des commandes d'un total supérieur à 1000. Description : « Affichez les noms des clients qui ont des commandes avec total > 1000. » Schéma : « SQLite, customers(id integer, name text), orders(id integer, customer_id integer, total real) ». L'outil peut proposer une sous-requête avec IN ou une jointure avec DISTINCT.

Les deux variantes sont possibles, mais se comportent différemment. Une sous-requête avec IN renverra chaque client une seule fois, s'il n'y a pas de NULL dans orders.customer_id. Une jointure avec DISTINCT supprimera aussi les doublons, mais avec un grand nombre de commandes, elle peut être moins efficace. L'outil n'optimise pas les requêtes, donc le choix reste entre vos mains.

Vérifiez que la sous-requête renvoie les corrects customer_id et que la condition total > 1000 n'écarte pas les lignes nécessaires à cause de NULL. Exécutez la requête sur des données de test et comparez la liste des clients avec l'attendu.

Entrée : « Affichez les noms des clients qui ont des commandes avec total > 1000. » Schéma : « SQLite, customers(id integer, name text), orders(id integer, customer_id integer, total real) ». Résultat possible : SELECT name FROM customers WHERE id IN (SELECT customer_id FROM orders WHERE total > 1000);

Comment vérifier la requête générée

Lisez d'abord la requête dans son intégralité et vérifiez chaque nom de table et de champ avec le schéma réel. Les fautes de frappe et les champs superflus -- le problème le plus fréquent, car l'outil ne voit pas votre base de données.

Si la requête utilise des fonctions d'agrégation, assurez-vous que tous les champs non agrégés sont inclus dans GROUP BY. Vérifiez le traitement des NULL : l'outil pouvait supposer que les valeurs ne sont pas vides. Si nécessaire, ajoutez manuellement COALESCE, IS NULL ou filtrage.

Exécutez la requête dans un environnement de test sur un petit jeu de données et comparez le résultat avec l'attendu. Si le résultat est incorrect, analysez quelle hypothèse l'outil a faite, et corrigez la description ou le schéma. N'utilisez pas la requête générée en production sans vérification.

Limites et erreurs typiques

SQL-maître ne se connecte pas à la base de données, n'exécute pas les requêtes et ne renvoie pas de données. Il ne vérifie pas l'existence des tables et des champs, ne prend pas en compte les particularités de vos données et ne garantit pas l'optimisation de la requête. Le modèle peut commettre des erreurs, donc le résultat nécessite toujours une vérification manuelle.

L'outil ne supporte pas l'exportation en DOCX ou PDF, n'effectue pas de traitement par lots, ne sauvegarde pas l'historique et ne s'intègre pas avec les bases de données ou les systèmes de contrôle de version. Seule la sortie textuelle est disponible, que l'on peut copier ou télécharger en TXT. Limites de longueur : premier champ jusqu'à 8000 caractères, second -- jusqu'à 1000 caractères.

Erreurs typiques lors de l'utilisation de l'outil : description de tâche trop générale, absence d'indication de SGBD, schéma incomplet sans types et relations, ignorance des NULL. La correction de ces points augmente notablement la qualité du SQL généré.