Discussion :

[sylvaine]

Bonjour,

Excusez-moi, ça va être un peu long pour bien m'exprimer.
Je n'arrive pas à résoudre mon problème, pourtant j’y ai passé des heures, peut-être s’agit-il d’un truc tout simple ?

Dans ma base de données Access2000, j'ai trois tables:

Code :

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

1
2
3
4
5
Eleve (RefE, NomE, PrenomE, FormationE)
 
Support (RefS, NomS, SerieS)
 
Test (RefT, DateT, NoteT, RefS#, RefE#)

--> Dans la table Test, RefE et RefS sont des clés étrangères.



Je souhaite faire une requete affichant la liste des support les MOINS vus (dont les supports jamais vus bien sûr).

J'ai réussi à faire une requête , mais elle me donne seulement les supports les moins vus PARMI les supports vus :
Avec le code SQL suivant (créé par Access) :

Code :

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

1
2
3
4
5
6
7
SELECT TOP 1 [NomE] & " " & [PrenomE] AS Elève, [NomS] & "-" & [SerieS] AS Support, Count(Test.RefT) AS Total, Elève.RefE
 
FROM Support INNER JOIN (Elève INNER JOIN Test ON Elève.RefE = Test.RefE) ON Support.RefS = Test.RefS
 
GROUP BY [NomE] & " " & [PrenomE], [NomS] & " " & [SérieS], Elève.RefE
 
ORDER BY Count(Test.RefT);

J’obtiens le support le moins vu pour chaque élève, avec le nombre de fois où il l’a vu. Ca donne (exemple):

• Leclerc Aurore // MATHS – Multiplications par 10 // 1
  
  Darnault Fidji // FRANÇAIS – Verbes du troisième groupe // 3

Etc… Mais si un support n’a jamais été testé, il ne s’affiche pas.





A côté de ça, j’ai fait une requête appelant une autre requête qui me donne les supports NONS VUS :

Code :

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

1
2
3
SELECT DISTINCT [Elève].[RefE], [NomE] & " " & [PrenomE] AS Elève, [NomS] & " " & [SérieS] AS Expr1, [ISNull].[RefS]
 
FROM ISNull, Elève INNER JOIN Test ON [Elève].[RefE]=[Test].[RefE];

Elle appelle la requete nommée IsNull:

Code :

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

1
2
3
4
5
SELECT Support.NomS, Support.SérieS, Requête2.RefS
 
FROM Support LEFT JOIN Requête2 ON Support.RefS = Requête1.RefS
 
WHERE (((Requête1.RefS) Is Null));

Qui elle-même appelle la Requête1 :

Code :

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

1
2
3
4
5
SELECT DISTINCTROW Elève.RefE, Elève.NomE, Elève.PrenomE, Test.RefT, Test.RefS
 
FROM Elève INNER JOIN Test ON Elève.RefE = Test.RefE
 
GROUP BY Elève.RefE, Elève.NomE, Elève.PrenomE, Test.RefT, Test.RefS;

Le problème avec cette requête c’est qu’elle me renvoie toujours la même liste de supports (ceux qui n’ont JAMAIS été vus, par AUCUN élève). Or, je veux qu’elle renvoie les supports nons vus pour chaque élève, et cette liste doit différer selon la valeur de RefE qui est dans le formulaire de base).

Pour la requête des supports nons vus, j’ai essayé d’utiliser NOT IN ou NOT EXISTS basée sur une requête regroupant les supports vus pour chaque élève, mais le résultat de la requête est vide ! Logique, puisque les supports NONS vus n’apparaissent pas dans les supports VUS. J’ai enfin essayé de mettre la condition SupportsVus.RefS <> Support.RefS mais le même problème se pose.

Du coup, j’ai essayé la « requête de non-correspondance d’Access, mais je retombe sur le problème de la liste qui ne varie pas pour chaque élève. Grrrr….

Je remercie d’avance celui qui pourra m’aider.

[SQLpro]

Pour obtenir les "moins" => agrégat MIN.
Pour obtenir les absents => requête ensembliste avec EXCEPT. Si pas implémenté, alors utiliser les équivalences (NOT IN, NOT EXISTS)
A lire sur le sujet :
http://sqlpro.developpez.com/SQL_AZ_...ENSEMBLEexcept

Maintenant quelques conseils :
C'est une gande abération que de ne pas respecter la norme SQL en matière de noms d'objets (tables, colonnes...) En effet les accents, espaces, signe divers SONT INTERDITS et ne peuvent te conduire qu'à de gravec ennuis. De plus l'utilisatio du crochet n'existe pas dans la norme (spécificté imbécile de MS )

En plus tes clauses de jointures sont extravagantes et syntaxiquement incorrecte.

Enfin ISNULL n'existe pas en SQL c'est propre à Access. En SQL c'est IS NULL, IS NOT NULL.

Un bon conseil, apprend le SQL, et revient nous voir pour tes problèmes, mais avec un tel code et un modèle aussi anormal il est évident que tu n'arrivera pas à retrouver tes petits !

Mon livre, comme mon bouquin peuvent t'y aider !

A +

[sylvaine]

Ok , merci pour l'article (pour le reste vous me faîtes peur! )
Mes jointures bizarres, en fait, c'est Access qui les a créées. Moi je mettais des Where quand j'apprenais SQL sans Access, et maintenant je suis perdue. Parfois j'utilise des mots d'Access dans mes requêtes SQL.
Merci

[sylvaine]

Le retour, je reviens sur ce vieux sujet pour te dire que finalement, j'étais justement en train d'apprendre SQL à cette époque et que je ne pense pas qu'il faille dénigrer Access comme base de données, car pour moi, il remplit toutes les conditions pour porter ce titre. Chaque SGBD porte son propre SQL. Maintenant j'étudie le PL/SQL, j'ai également vu PosgreSQL, etc... Avec du recul, mes erreurs n'étaient pas abherrantes mais simplement normales pour quelqu'un qui étudierait seul chez soi dans un seul SGBD. Moi je trouve que le fait qu'un SGBD comporte des spécifications n'est pas une débilité, mais plutôt un truc pratique. Et que ces spécificités devraient peut-être devenir des normes SQL, les unes jouxtant les autres.

[SQLpro]

Vieux débat, auquel je suis attaché.

SQL est une norme. C'est même l'une des rares normes ISO donc internationale de l'informatique...

Ne pas la respecter implique les mêmes problématique que les différences d'écartement des rails entre les différentes compagnies de chemin de fer. L'espagne par exemple possède un écartement des rails non standard.
C'est pourquoi les trains transfrontaliers doivent passer la frontière à 20 km/h max pour rapporter ce réglacge différentiel. Donc perte de temps. De plus le matériel ferroviaire est particulier, donc plus coûteux. Enfin, l'espagne n'a pas de TGV et ses infrastructures ferroviaires vieillissantes ne sont pas prêtes de se renover car il faut fabriquer du matériel spécifique... Que d'avantages en effet !!!

Soyez réaliste...
Avant l'introduction des chemins de fer, chaque village de France et de Navarre avait sa propre heure. Il en est résulté de nombreux accidents de chemin de fer. Est-ce un bienfait ?
Avant le révolution, chaque seigneur avait ses propres mesures de commerce (poids, volume, longueur). Cela présentait un avantage certain, : les commerçants étaient inféodés à leur seigneur. Pour commercer ils étaient même obligés d'acheter les étalons de mesure au seigneur à un prix exhorbitant. Aujourd'hui cela s'apelle un copyright... Préférez vous payer alors qu'un standard intelligent, gratuit et portable existe ?
D'uatant que la norme est souvent bien plus intelligente que la spécificité de chaque éditeur. En effet ce sont les éditeurs et les utilisateurs qui la définisse. Libre à eux de ne pas la respecter... Mais alors ne venez pas vous plaindre lorsque vous aurez tôt ou tard un portage à accomplir !

Un petit exemple. La norme SQL définit la fonction TRIM, qui prend un paramètre dont les valeurs peuvent être LEADING, TRAILING ou BOTH (en tête, en queue ou les deux).
Avec SQL Server si l'on veut faire un TRIM des 2 côtés, il faut faire :
RTRIM(LTRIM(...)). Croyez vous que cette double imbrication de fonction soit plus rapide que TRIM(... BOTH) ???
Je vous laisse méditer le sujet !

A +

[sylvaine]

merci