Proposer une tâche SQL avec sa propre base de données

Une tâche SQL comporte deux onglets : la requête que l’élève écrit, et le schéma qui crée et remplit la base de données sur laquelle elle s’exécute. C’est vous qui préparez les deux.

Le schéma fait partie de la tâche

Vous écrivez le `CREATE TABLE` et les `INSERT` : tous les élèves interrogent les mêmes données, et vous savez quelle est la bonne réponse. Les tables sont affichées à côté de l’éditeur, si bien que personne n’a à retenir le nom d’une colonne.

Il s’agit de SQLite, exécuté dans un nouveau conteneur à chaque essai : un élève qui supprime une table ne supprime que sa propre copie, jamais celle d’un autre. Chaque exécution construit une base neuve en mémoire, en appliquant votre schéma puis la requête.

Une nouvelle tâche SQL s’ouvre avec une petite base scolaire prête à être interrogée : students, courses et enrollments, cinq lignes dans chaque table, de quoi essayer un select, un where, un order by et une jointure avant d’écrire la vôtre.

Un éditeur SQL avec une requête, la liste des tables interrogées à côté, et une zone de résultats
La requête à gauche, les tables interrogées à droite, et les lignes renvoyées en dessous. Personne n’a à retenir le nom d’une colonne.

Exécuter la requête

« Exécuter » lance la requête et affiche les lignes obtenues. « Exécuter le schéma » reconstruit la base de données : c’est ainsi qu’on repart d’une base propre après un essai qui a mal tourné.

La corriger automatiquement avec un corrigé

Donnez un corrigé à la tâche et « Exécuter les tests » la corrigera à votre place. Un troisième onglet, « Corrigé », contient votre propre requête. La requête de l’élève et la vôtre s’exécutent sur le même schéma, et leurs lignes sont comparées sans tenir compte de l’ordre mais en tenant compte des doublons : une réponse qui arrive dans un autre ordre est acceptée, et une réponse qui renvoie une ligne une fois là où elle devrait la renvoyer deux fois ne l’est pas. Il faut les mêmes colonnes dans le même ordre, mais les noms de colonnes ne sont pas comparés.

Le résultat est une simple réussite ou un simple échec, sans demi-point ni décompte. Une requête qui ne peut pas s’exécuter affiche « Exécution impossible » plutôt que « échec », car une erreur de syntaxe et une mauvaise réponse méritent des retours différents. Le corrigé reste caché aux élèves sauf si vous cochez « Montrer le corrigé aux élèves, en lecture seule », et le bouton leur est proposé dans les deux cas : un élève peut donc toujours vérifier son travail.

Dans une leçon, et verrouiller le schéma

Un bloc de code SQL dans une leçon a les deux mêmes onglets : écrivez le schéma une fois et chaque élève exécute ses requêtes sur ces tables, sans quitter la leçon. Il en va de même pour une tâche SQL ajoutée à une leçon.

Cochez « Verrouiller le schéma pour les élèves » et ils voient le schéma sans pouvoir le modifier : tout le monde interroge les données que vous avez fixées. Laissez-la décochée et chaque élève peut modifier sa propre copie.

Questions fréquentes

Quel dialecte SQL est utilisé ?
SQLite, suffisamment proche de la norme, et qui ne nécessite aucun serveur.
Un élève peut-il voir les données avant de les interroger ?
Oui. Les tables sont listées à côté de l’éditeur, avec leurs premières lignes.