Discussion :

[manel_dkl]

Bonjour,

Je suis en BTS Assistant de gestion PMI-PME. J'ai énormément de mal dans la matière Gestion du système d'information. Ca fait 1 mois que je suis sur un devoir portant sur les bases de données. J'ai effectué la 1ère partie , il me reste la 2ème sur le langage SQL. Voilà ce que j'ai fais pour l'instant dites moi si c'est bon ou pas et pour le reste pouvez-vous m'aider ? j'ai regardé tous les cours mais en vain. Je vous ai joint mon sujet.

Pour la 1ère requête j'ai mis :

Code :

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

1
2
3
SELECT * 
FROM STAGIAIRE
ORDER BY NomSta DESC

Pour la seconde j'ai fais :

Code :

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

1
2
3
SELECT nom, prénom
FROM STAGIAIRE 
WHERE Ville=Toulon

Pour la 4ème j'ai fais :

Code :

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

1
2
3
SELECT * 
FROM EPREUVE
WHERE date BETWEEN 01/05/2016 AND 01/07/2016

Pour la 5ème :

Code :

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

1
2
SELECT SUM (Coefficient) 
FROM MATIERE

Merci

[escartefigue]

Code :

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

1
2
3
4
 Pour la 1ère requête j'ai mis : 
SELECT * 
FROM STAGIAIRE
ORDER BY NomSta DESC

Cette 1ère réponse est syntaxiquement et fonctionnellement correcte, par contre, il est fortement recommandé de ne jamais utiliser de select *
A remplacer par la liste des colonnes utiles à votre traitement, y compris si ces colonnes utiles sont la totalité des tables ou vues
La raison est que si la table ou la vue évolue, le résultat de la requête va changer et donc impacter le résultat.
Et comme le plus souvent, même si ici ce n'est pas le cas, on n'a besoin que d'une partie des attributs, on évite de transporter les colonnes inutiles car ça génère de la charge réseau au détriment des performances.
Pensez à utiliser les balises CODE (symbole dièse de la barre d'outils) pour encadrer vos requêtes
Remarques valables également pour les requêtes suivantes bien sur

Code :

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

1
2
3
4
Pour la seconde j'ai fais : 
SELECT nom, prénom
FROM STAGIAIRE 
WHERE Ville=Toulon

La colonne dans la table est "villeSta" et non Ville
De plus, toute chaine de caractères doit être encadrée par des codes : where villeSta = 'Toulon'
Enfin, il est risqué de tester une chaine de caractères sans convertir en majuscules ou en minuscules, car 'Toulon' n'est pas 'toulon', ni 'TOULON', ni 'ToUlOn' etc...
il est donc plus prudent d'utiliser une fonction uppercase ou lowercase : WHERE upper(villeSTA)='TOULON'

Pour la 4ème j'ai fais :

Code :

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

1
2
3
SELECT * 
FROM EPREUVE
WHERE date BETWEEN 01/05/2016 AND 01/07/2016

La encore, attention à bien lire l'énoncé, la colonne ne se nomme pas 'date' mais 'dateEp' et à raison, 'date' est un nom réservé à éviter dans les noms de colonnes
En général, on teste les dates sous la forme 'JJ-MM-CCAA' mais ça peut dépendre du SGBD et des options locales

Pour la 5ème :

Code :

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

1
2
SELECT SUM (Coefficient) 
FROM MATIERE

OK pour ça, même si je ne vois pas bien l'intérêt fonctionnel de cette somme, ni pédagogique de l'exercice
J'espère qu'on vous a appris le regroupement par GROUP BY le plus souvent associé aux fonctions d'agrégation de façon à produire des sous-totaux

[manel_dkl]

Merci pour ta réponse. Mais je n'ai pas compris pourquoi ce n'est pas correct de mettre * tout seul ? Du coup pour la deuxième requête j'ajoute Sta après nom et prénom ou pas la peine ? (nom_Sta prénom_Sta)

Pour la requête numéro 3 du sujet est-ce bon si je fais ça :

Code :

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

1
2
3
SELECT *
FROM ÉTUDIENT
WHERE épreuve = mathématiques  AND note<10

Pour la La requête 6 :

Code :

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

1
2
SELECT COUNT * 
FROM EPREUVE

Et pour les requêtes 7 et 8 j'ai du mal. Vous pouvez m'aider ?

Merci.

[escartefigue]

Select * n'est pas incorrect, c'est dangereux et contre-performant

Si une requête select * renvoie par exemple 3 colonnes aujourd'hui, quand quelqu'un ajoutera une colonne dans la table, la même requête renverra 4 colonnes
Du coup
- tous les traitements qui appellent cette requête devront être modifiés pour tenir compte de cette nouvelle donnée en retour, si la requête est dans un accesseur, c'est lourd de conséquences, si c'est dans un trigger c'est pire, et si l'optimiseur utilisait jusque là un index couvrant, ce ne sera plus le cas, les perfs vont donc lourdement baisser etc...
- les traitements qui n'ont pas besoin de la nouvelle colonne transportent des données inutiles, ça crée de la charge réseau au détriment des copains qui attendent de la place dans les tuyaux
Par ailleurs
- si le select * concerne une requête avec jointure, vous transportez deux fois les colonnes de jointure, donc à minima une fois de trop
- si le filtrage est sur critère d'égalité (where colonne = valeur) ou sur une liste de valeurs (where colonne in ...) vous transportez des données dont vous connaissez déjà la valeur

Notez que dans beaucoup d'entreprises, les requêtes select * sont interdites en production pour ces raisons

[escartefigue]

Pour la requête numéro 3 du sujet est-ce bon si je fais ça :

Code :

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

1
2
3
SELECT *
FROM ÉTUDIENT
WHERE épreuve = mathématiques  AND note<10

Vous n'êtes décidément pas très attentif à l'énoncé la table ETUDIENT n'est pas dans l'énoncé, et étudiant s'écrit avec un "a"
Je suppose qu'il s'agit de la question 2.3, auquel cas il faut mettre en œuvre des jointures, ce que vous n'avez pas fait ici.
Comme mentionné précédemment, une chaine de caractères doit être encadrée par des quotes, donc WHERE épreuve = mathématiques est incorrect.

[Invité]

Bonjour

Petit complément, éviter les caractères accentués dans les noms des champs.

Philippe

[aieeeuuuuu]

Bonjour,

Enfin, il est risqué de tester une chaine de caractères sans convertir en majuscules ou en minuscules, car 'Toulon' n'est pas 'toulon', ni 'TOULON', ni 'ToUlOn' etc...
il est donc plus prudent d'utiliser une fonction uppercase ou lowercase : WHERE upper(villeSTA)='TOULON'

Pas d'accord. Cela pourrait nuire à l'utilisation d'index en plus.
Pour adresser cette problématique, il faut utiliser le bon classement pour la colonne contenant le nom de la ville.
Au pire, spécifier un classement insensible à la casse dans la requete (mais là aussi, ça peut nuire à l'utilisation d'index si le classement de la colonne est différent)

La encore, attention à bien lire l'énoncé, la colonne ne se nomme pas 'date' mais 'dateEp' et à raison, 'date' est un nom réservé à éviter dans les noms de colonnes
En général, on teste les dates sous la forme 'JJ-MM-CCAA' mais ça peut dépendre du SGBD et des options locales

L'idéal pour les dates est d'utiliser le format ISO : 'AAAAMMJJ', ou 'AAAA-MM-JJThh:mm:ss'

[aieeeuuuuu]

et si l'optimiseur utilisait jusque là un index couvrant, ce ne sera plus le cas, les perfs vont donc lourdement baisser etc...

tout à fait, et c'est même à mon sens la première des raisons d'éviter le SELECT *, qui a son corollaire : même sans ajout de colonne, si un index couvrant existe, les colonnes supplémentaires inutiles engendrées par un SELECT * pourraient le rendre non couvrant, et donc obliger le moteur a effectuer des accès à la table, voire a ne pas utiliser l'index du tout.

[escartefigue]

L'idéal pour les dates est d'utiliser le format ISO : 'AAAAMMJJ', ou 'AAAA-MM-JJThh:mm:ss'

Je me suis trompé, je voulais dire CCAA-MM-JJ et non JJ-MM-CCAA

[aieeeuuuuu]

oui, mais le format de date simple avec les "-" n'est pas ISO non plus, ce qui peut parfois prêter à confusion voire créer des erreurs :

Une exemple sous SQL Server :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SET DATEFORMAT ydm;
SELECT 1 AS ligne, CAST('2018-03-06' AS DATETIME) AS Result
UNION ALL
SELECT 2, CAST('2018-03-06' AS DATE)
UNION ALL
SELECT 3, CAST('20180306' AS DATETIME)
UNION ALL
SELECT 4, CAST('20180306' AS DATE)
;

1	2018-06-03 00:00:00.000
2	2018-03-06 00:00:00.000
3	2018-03-06 00:00:00.000
4	2018-03-06 00:00:00.000

C'est pourquoi je prefére :
Date simple : '20180420'.
Date/Heure : '2018-04-20T13:45:28'.
Afin de lever toute ambiguïté

[manel_dkl]

Merci de prendre le temps de me répondre mais vous ne m'aidez pas vraiment.

Vous donnez des explications très approfondies avec des termes très techniques cependant, comme je l'ai mentionné je ne suis qu'en BTS AG et ce qu'on fait en Gestion du système d'information est très très superficiel ce n'est qu'une approche, pour être un interlocuteur "parfait". Par conséquent, je ne comprends pas vos explications. Et j'aimerais bien qu'on m'apporte de l'aide concrètement concernant les requêtes svp. J'ai personne pour m'aider, j'étudie à distance, je n'ai jamais étudier cette discipline auparavant et j'ai beaucoup de mal. Vous me reprochez mes erreurs mais vous ne me dites pas ce que je dois faire exactement, c'est pas comme si je disais de faire mon devoir à ma place.

Y-aurait-il une âme charitable qui pourrait me dire ce que je dois faire et m'aider précisément ?

[manel_dkl]

Vous n'êtes décidément pas très attentif à l'énoncé la table ETUDIENT n'est pas dans l'énoncé, et étudiant s'écrit avec un "a"
Je suppose qu'il s'agit de la question 2.3, auquel cas il faut mettre en œuvre des jointures, ce que vous n'avez pas fait ici.
Comme mentionné précédemment, une chaine de caractères doit être encadrée par des quotes, donc WHERE épreuve = mathématiques est incorrect.

Si si, je suis très attentive à l'énoncé. Etudiants est bien dans l'énoncé.
Désolée si j'ai du mal dans cette matière hein..

[aieeeuuuuu]

Pour les requêtes que vous avez présentées, le principal problème est l'absence de guillemets simples autour des chaines de caractères (y compris pour les dates).

Pour la 6, elle est très similaire à la 5, voyez la fonction d'agrégation COUNTPour les questions 3, 7 et 8, il faut au préalable savoir faire une jointure, pour cela vous pouvez lire cet article.

[escartefigue]

1	2018-06-03 00:00:00.000
2	2018-03-06 00:00:00.000
3	2018-03-06 00:00:00.000
4	2018-03-06 00:00:00.000

Aucune différence entre les lignes 2 et 4 qui sont de type date, comme dans le sujet abordé ici
Je suis surpris du comportement du datetime avec la ligne 1, c'est peut être un bug SQL server, à vérifier avec du TimeStamp, en principe synonyme

Vous donnez des explications très approfondies avec des termes très techniques cependant, comme je l'ai mentionné je ne suis qu'en BTS AG et ce qu'on fait en Gestion du système d'information est très très superficiel ce n'est qu'une approche, pour être un interlocuteur "parfait". Par conséquent, je ne comprends pas vos explications. Et j'aimerais bien qu'on m'apporte de l'aide concrètement concernant les requêtes svp. J'ai personne pour m'aider, j'étudie à distance, je n'ai jamais étudier cette discipline auparavant et j'ai beaucoup de mal. Vous me reprochez mes erreurs mais vous ne me dites pas ce que je dois faire exactement, c'est pas comme si je disais de faire mon devoir à ma place.
Y-aurait-il une âme charitable qui pourrait me dire ce que je dois faire et m'aider précisément ?

Désolé si les explications qui précèdent vous semblent confuses, pour en revenir à l'essentiel :
- mettez des quotes (apostrophes) autour des chaines de caractères, par exemple
where VILLE='Orléans' est correct mais where VILLE=Orléans ne l'est pas

- n'utilisez jamais select *, par exemple
select codeMat, libelleMat, coefMat from matiere est une bonne façon d'écrire une requête, mais select * from matierene l'est pas

Si si, je suis très attentive à l'énoncé. Etudiants est bien dans l'énoncé.

Vous avez raison, dans le libellé de la question 2.3 il est question d'étudiant, mais vous constaterez que la table s'appelle "STAGIAIRE"
Si le rédacteur des questions avait été rigoureux, il aurait précisé que étudiant est un synonyme de stagiaire, ou mieux, il aurait toujours utilisé le même terme
Donc, pour la question 2.3 il faut faire la requête sur la table "STAGIAIRE"

[Wks882]

Bonjour,
Nouvelle sur le forum, je n'arrive pas à trouver le sujet que vous avez joint à votre message sur ce forum.
Pourriez-vous m'indiquer où le trouver s'il vous plaît ?
Je vous remecie d'avance pour votre réponse.
Bonne journée à vous

[SQLpro]

;;;
Enfin, il est risqué de tester une chaine de caractères sans convertir en majuscules ou en minuscules, car 'Toulon' n'est pas 'toulon', ni 'TOULON', ni 'ToUlOn' etc...
il est donc plus prudent d'utiliser une fonction uppercase ou lowercase : WHERE upper(villeSTA)='TOULON'

Mauvais conseil, il vaut mieux jouer sur la collation parce que l'emploi d'une fonction empêche l'utilisation d'index, alors que la collation ne l'interdit pas !

A +

[escartefigue]

oui, mais le format de date simple avec les "-" n'est pas ISO non plus, ce qui peut parfois prêter à confusion voire créer des erreurs :

Une exemple sous SQL Server :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SET DATEFORMAT ydm;
SELECT 1 AS ligne, CAST('2018-03-06' AS DATETIME) AS Result
UNION ALL
SELECT 2, CAST('2018-03-06' AS DATE)
UNION ALL
SELECT 3, CAST('20180306' AS DATETIME)
UNION ALL
SELECT 4, CAST('20180306' AS DATE)
;

Bonjour,

Je reviens à la charge sur ce point
D'après la documentation officielle, le format ISO des dates requiert les séparateurs "-"
cf. https://www.iso.org/iso-8601-date-and-time-format.html
ou encore https://fr.wikipedia.org/wiki/ISO_8601

Il faut donc faire attention si effectivement le format de date est "YDM", ce qui est quand même très rare en Europe continentale, et surtout, ce qui n'est pas conforme à la norme ISO qui stipule que les éléments doivent être énumérés de gauche à droite en allant de la précision la plus faible (l'année) vers la plus forte (le jour donc si date, les nanosecondes si timestamp).