Discussion :

[reseau-emploi]

Bonjour,

j'ai mis en place un test de compétence SQL, j'aimerais
bien avoir un retour de quelques personnes qui s'y connaissent
bien en SQL...

http://www.reseau-emploi.com/tests/tests-competence.php
(puis cliquer sur SQL)

Merci d'avance pour vos remarques... N'hésitez pas à me
faire part de toute erreur

(note : pour lancer le test, vous devez avoir un plug-in java relativement à jour)

[gk14fire]

Salut

J'ai expérimenté ton test de compétences.
6/10 pour un lundi matin, ça va encore :-)

Plutôt sympa comme outil.

En ce qui concerne mes remarques :

• Visiblement, ce sont toujours les mêmes questions, ce serait bien d'avoir un plus grand choix de questions et de les tirer au sort au hasard

• En poursuivant cette idée, peut-être regrouper les questions par catégories (Bases, Index, Vues, Types de données, etc...)

• Une des questions traite de l'insertion de données dans une table. Tu parles d'un champ "prenom" alors que dans la structure il y a un champ "url" à la place, je croyais au piège, mais en regardant les réponses possibles, j'ai vu qu'il s'agissait d'une petite erreur

• Parfois, il serait plus judicieux de mettre une checkbox avec les réponses (plutôt que des radio button) : cela permettrait de choisir directement une réponse, plutôt que "la requête 2 est correcte", et aussi de multiplier les combinaisons de type "requête 3 et 4 correctes"

• Dans la visualisation des résultats, ce serait bien de pouvoir donner les résultats par catégorie (cf. 2ème remarque), de pouvoir visualiser toutes les questions (même celles pour lesquelles la réponse était bonne) et enfin d'avoir une petite explication de la réponse (pourquoi telle affirmation est fausse, donner les tailles des champs lorsqu'on demande quel est le type le plus approprié, etc...)

Sinon beau travail, bonne continuation !

A+

[Magnus]

5/10 avec un coup de fil passé entre temps => je n'avais pas remarqué que c'est en temps limité !

Q 4/10 : la notion de colonne incrémentable ne fait pas partie de la norme SQL et d'ailleurs tous les SGBD ne proposent pas cette fonctionnalité (ex : Oracle).

Q 4/10 : toutes les requêtes génèreraient une erreur car il n'existe pas de colonne prenom dans votre table

Q 6/10 : LIMIT ne fait pas partie de la norme SQL

Q 7/10 : une vue ne stocke jamais de données et d'autre part, sous certaines conditions, on peut ajouter des données à une vue donc 2 réponses conviennent
Ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
10g CYRIL> CREATE TABLE DVP(A NUMBER);
 
Table créée.
 
10g CYRIL> 
10g CYRIL> INSERT INTO DVP VALUES (12);
 
1 ligne créée.
 
10g CYRIL> INSERT INTO DVP VALUES (120);
 
1 ligne créée.
 
10g CYRIL> INSERT INTO DVP VALUES (1200);
 
1 ligne créée.
 
10g CYRIL> INSERT INTO DVP VALUES (12000);
 
1 ligne créée.
 
10g CYRIL> INSERT INTO DVP VALUES (120000);
 
1 ligne créée.
 
10g CYRIL> INSERT INTO DVP VALUES (1200000);
 
1 ligne créée.
 
10g CYRIL> 
10g CYRIL> CREATE VIEW V_DVP AS
  2  SELECT A
  3  FROM   DVP
  4  WHERE  A > 1900;
 
Vue créée.
 
10g CYRIL> 
10g CYRIL> INSERT INTO V_DVP (A) VALUES (1500000);
 
1 ligne créée.
 
10g CYRIL> SELECT *
  2  FROM   DVP;
 
         A
----------
        12
       120
      1200
     12000
    120000
   1200000
   1500000
 
7 ligne(s) sélectionnée(s).

D'autre remarques :
- votre test est tout simplement spécifique à MySQL
- vous faîtes vos jointures avec une syntaxe vieille de 20 ans : dans la clause WHERE et non dans la clause FROM (INNER JOIN, LEFT JOIN, CROSS JOIN, etc.)

Concernant la correction :
- Q1 : c'est faux car on ne peut pas utiliser un alias de colonne dans la clause HAVING
Ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
10g CYRIL> DROP TABLE TADHERENT;
 
Table supprimée.
 
10g CYRIL> 
10g CYRIL> CREATE TABLE TADHERENT (
  2    ID    INT PRIMARY KEY,
  3    ANNEE INT
  4  );
 
Table créée.
 
10g CYRIL>   
10g CYRIL> SELECT   ANNEE, COUNT(ID) AS CPT
  2  FROM     TADHERENT
  3  GROUP BY ANNEE
  4  HAVING   CPT > 5;
HAVING   CPT > 5
         *
ERREUR à la ligne 4 :
ORA-00904: "CPT" : identificateur non valide

[chrifo]

Bonjour,
J'ai quelques remarques qui j'espère t'apporteront quelque chose :
8/10, J'ai donc donné 2 réponses inexactes :

1ere réponse inexacte :

Create view ... as ...
Quelle est l'affirmation fausse à propos des vues ?
Réponse exacte : Des données peuvent etre ajoutées directement dans une vue
Votre réponse : Une vue est automatiquement modifiée si on modifie une table qu'elle référence

Une vue n'a pas de consistance, on peut tout à fait faire des insert sur une vue pour peu que la définition de celle ci le permette (conservation de l'unicité, par exemple simple projection).
En revanche, une modification DDL d'une table n'entrainera en aucun cas une modification des vues qui l'interrogent !

2e réponse inexacte :
La question porte sur des différences entre les types MySQL ... attention SQL <> MySQL

Je suis également tombé sur une question avec la définition de la table TSiteInternet(id,nom,url,commentaire) puis des insert(nom,prenom) sur cette table : toutes les réponses étaient donc fausses.

Une dernière petite remarque sur la question de la Banque avec la table TCompte : la réponse est PK sur id index sur numéro ... attention la création d'une PK engendre une contrainte, et même si la majorité des SGBD construisent l'index associé, cela n'a rien a voir avec du SQL. la bonne réponse devrait donc être index sur id + index sur numéro

[reseau-emploi]

Merci pour vos premières remarques,

j'ai corrigé la question 4

j'ai précisé que le test est un test SQL (MySQL)

je vais réfléchir à comment modifier la question sur les vues...
Si vous avez une idée intelligente pour remplacer la question
actuelle...

[reseau-emploi]

Pour le problème suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
10g CYRIL> SELECT   ANNEE, COUNT(ID) AS CPT
  2  FROM     TADHERENT
  3  GROUP BY ANNEE
  4  HAVING   CPT > 5;
HAVING   CPT > 5
         *
ERREUR à la ligne 4 :
ORA-00904: "CPT" : identificateur non valide

> ca marche sous MySQL... du coup maintenant
que j'ai précisé que c'est un test SQL (MySQL), maintenant
ca passe... (en fait, ca m'a l'air pénible Oracle )

[Magnus]

en fait, ca m'a l'air pénible Oracle

En fait non c'est le contraire : Oracle permet généralement beaucoup de manipulations qui ne figurent pas dans la norme SQL qui, elle, est contraignante.
Donc ce que j'essayais de vous dire à ce propos est que la norme SQL n'autorise pas l'utilisation d'un alias de colonne dans la clause HAVING ; Cf. cet article sur les groupements.

La norme SQL n'est pas MySQL (ni Oracle ou SQL Server ou DB2 ou ...) !