Bonjour !!
 
Suite a une petite série d'exo que j'ai a faire, je bloque sur certaines de mes requêtes a éffectuer
Voici les Tables de l'exercice :
http://img4.imageshack.us/i/tablesyb.jpg
http://img18.imageshack.us/i/tables2.jpg/
 
Voici les requêtes sql a faire :
 
1)Donner les régions visitées par le client 30
2)Donner le nom des clients qui ont eu l'occasion de faire de la voile
3)Donner les régions où il y a des clients mais pas de stations
4)Donner les noms des stations qui n'ont pas reçu de client américain
5)Quelles sont les stations dont toutes les activités ont un prix supérieur à 100.
 
Voici ce que j'ai commencer a faire mais je ne pense pas que ça soit bon
 
1) SELECT st.Region, FROM Station st, Sejour se, WHERE se.IdClient='30' AND se.Station = st.NomStation
2) SELECT c.nom FROM client c, Activité a, Séjour s WHERE S.idClient=c.id AND a.Libellé='Voile' GROUP BY c.nom
3) SELECT s.NomStation FROM Station s, WHERE NOT EXISTS (SELECT s.NomStation FROM Station)
...
n'étant pas sur du coup du NOT EXITS du coup je ne pense pas pouvoir faire pareil avec les autres
 
Merci de m'aider a corriger ça, si possible et de m'aider a me donner des pistes pour le reste.
Jawaya

les liens vers les images des tables ne fonctionnent pas.
bon sinon, pour ce que je peux te dire d'après ce que je vois, c'est que tu fais très mal tes jointures. les jointures se font avec des JOIN (INNER JOIN dans ton cas), et pas avec des WHERE.

voila j'ai remis bien les liens des tables !
ah bon?  
car ça viens de mes cours de ma fac :s
 
Ils me donnent des exemples de ce type :
 
SELECT C.Num_Cli, c.Nom,C.Prenom, R.Num_Representant,R.nom, R.Prenom
FROM Clients C, Representant R
WHERE C.Num_Representant = R.Num_Representant
 
(ceci est un exemple pour une autre table)
 
Ps : http://sqlpro.developpez.com/cours/sqlaz/jointures/ est une de mes sources pour me documenter et chercher

J'ai eu le même problème en BTS IG (Informatique de Gestion), les profs voulaient absolument nous faire faire des jointures avec des WHERE  

Le lien vers la 1ere table ne fonctionne pas
 
Sinon en ce qui concerne les jointures avec WHERE, voici ce que j'en pense : quand tu as une grosse requête avec des filtres partout, le fait d'employer (INNER|LEFT|RIGHT) JOIN permet de mieux distinguer les jointures. Avec des jointures WHERE, on ne distingue pas la jointure du filtre. Et si tu as plusieurs filtres, ça devient vite illisible/
Mais surtout, et ça je l'ai vu, si tu supprimes par mégarde le WHERE qui créé la jointure (ce qui peut arriver sur des grosses requêtes), tu créées un produit cartésien qui peut foutre le serveur à genoux le cas échéant.
Faut arréter les jointures avec WHERE, ça date quand même de 1986 ! Je comprends pas que les profs de fac enseignent encore cette méthode antédiluvienne.

 
 
suffit de bien indenter et ordonner la clause where, je vois pas où est le souci.
Quant au produit cartésien que tu mentionnes, on s'en rend très vite compte en regardant le plan d'exécution (chose qu'on fait systématiquement pour les grosses requêtes).
 
Si les profs de fac enseignent cette méthode (j'y ai eu droit aussi, meme si ca commence à dater   ), c'est  parce qu'ils utilisent Oracle et qu'Oracle ne se conforme pas à la norme ANSI (même si on peut le forcer) pour les clauses de jointures.
Ca ne se limite d'ailleurs pas à la fac : j'ai fait plusieurs sociétés, qui utilisent Oracle, et à chaque fois les conditions de jointure sont écrites de la même manière. Et je n'ai vu que très peu de produits cartésiens (écrits chaque fois par des novices ).
Heu, ceci étant, Jawaya, dans ta 2eme requete, tu as fait un bô produit cartésien dans la mesure où il manque une condition de jointure entre ta table activité et ta table client    
 
Bref, je n'utilise donc les inner/outer... qu'avec SQL Server...
 
Pour Jawaya, tu peux donc continuer à utiliser cette syntaxe sans pb sous Oracle, elle n'est en rien dangereuse ou obsolète, simplement elle est "limitée" à Oracle.

Non mais je crois réver en lisant ça...

Ce n'est pas parce qu'Oracle fait ses jointures comme un porc qu'il faut faire la même chose pour les autres SGBD ! La syntaxe INNER a été définie dans la norme ANSI/SQL99, et ce n'est pas pour rien. Car même si le risque de produit cartésien est limité, il existe néanmoins, et ça me suffit pour totalement écarter les jointures par WHERE. Ca, plus le fait que si la requête comporte un grand nombre de clauses WHERE (ce qui arrive très souvent) il est difficile de distinguer les "vrais" WHERE (ceux qui filtrent effectivement les données à renvoyer) des WHERE utilisés pour le critère de jointure, ce qui peut rendre le debuggage d'une requête SQL assez pénible. Le SQL est déjà sufisamment pénible comme ça sans en rajouter davantage.

Si tu utilises JOIN d'un coté et WHERE de l'autre, alors tu visualises d'un seul coup d'oeil les filtres et les jointures. Quant à l'indentation, entre les clauses, les éventuelles sous requêtes, les groupements, elle peut vite s'avérer encore plus illisible qu'une requête sans indentation.

Pour Jawaya, continue d'utiliser WHERE si tu dois l'utiliser, mais débarasse t'en dés que tu peux. Commence donc ta carrière en prenant de bonnes habitudes.

edit:

Pour info, cette erreur aurait été signalée de suite par le SGBD s'il avait utilisé une jointure INNER

Où as tu lu que je disais qu'il fallait faire la même chose pour les autres SGBD ????
j'ai dit que j'utilisais les clauses inner outer join avec SQL Server !
 
Je te sens un peu extrémiste quand tu dis "Non mais je crois réver en lisant ça".
On a le même âge, et donc j'imagine une expérience professionnelle sensiblement équivalente.  
Or, je n'ai encore jamais vu de code SQL écrit sous Oracle utilisant la norme ANSI, que ce soit à la fac, ou en entreprises.  
Et je n'en vois toujours pas la nécessité, malgré ton laïus ! Je suis pourtant DBA depuis 12 ans et j'en ai cotoyé un certain nombre, qui tous écrivent de cette façon.
 
Je pense simplement qu'il y a 2 écoles :
- Oracle d'un coté ( jette un oeil à leurs supports de cours : ils ne connaissent pas la norme SQL99 ! déjà qu'ils ont du mal avec la 92...)
- le reste du monde (en fait SQL Server et mysql essentiellement)
 
Je ne prends partie pour aucun des 2, je te fais juste part de la pratique que je constate, et c'est avant tout une affaire d'habitudes.
 
De plus, et pour info, en versions antérieures à la 9i d'Oracle (et il doit en trainer encore des paquets dans les entreprises), la syntaxe inner/outer join n'est pas reconnue et ne te laisse donc aucun choix (à part changer de sgbd) !

 
Intégriste!
 

J'ai appris avec des JOIN sur oracle quelque part entre 1998 et 2000 à la fac, faut pas déconner non plus

J'ai pas dit que c'était systématique    
mais c'était mon cas, 5 ans avant toi, et c'est a priori le cas de 2 personnes sur ce topic  

D'ailleurs je me rappelle avoir beaucoup utilisé "natural join" à l'époque, et je l'ai jamais revu depuis...tout le monde préfère écrire les conditions de jointure explicitement...

Au temps pour moi, j'ai lu de travers
 

Oui, je suis extrémiste car les chieries d'Oracle je les connais bien et elles m'ont occasionné pas mal de nuits blanches dont je me serais bien passé. Ce qui m'a hérissé le poil, c'est que tu sembles minimiser le risque de produit cartésien. Je veux bien croire que le risque qu'il se produise soit limité, mais il existe. Et en matière de données, j'ai pour habitude d'essayer dans la mesure du possible de tendre vers le risque 0. Si le SGBD autorise les JOIN, alors il faut les utiliser.
 
Je suis d'accord avec toi quand tu dis que SQL99 a été implémenté qu'à partir d'Oracle 9i. Cependant, cette version date de 2002 et il est fort probable qu'une grande majorité d'entreprises soit au moins équipée de cette version (même si je sais que certaines sont encore sous 8i).
Quand Jawaya sortira de la fac, la probabilité est grande pour que, s'il utilise Oracle, la version qu'il utilisera soit au moins >= 9i. Dés lors, pourquoi ne pas le sensibiliser dés maintenant à la syntaxe SQL99 ? Uniquement parce qu'il a 5% de chances de tomber dans sa future carrière sur une boite qui utilisera encore 8i ? Je suis désolé, mais non. Les jointures "à la" SQL99 offrent trop d'avantages et de sécurité pour les passer sous silence sous le prétexte qu'un prof de fac n'aura même pas pris la peine de réactualiser son cours.
 

C'est pas de ma faute si certains DBA hésitent à se sortir les doigts du cul pour faire du code propre. J'ai travaillé dans 2 entreprises avant qui étaient sous 9i, et je me suis toujours efforcé de faire mes jointures correctement (surtout qu'à chaque fois, le support ANSI était activé, rajoutant encore un peu plus dans l'absurdité).
 

Je vois pas quoi te dire de plus
Si tu préfères t'obstiner à écrire des requêtes vieille école alors que tu as les moyens de les écrire correctement, libre à toi. Si entre ça

et ça

tu préfères la 1ere solution, ben continue comme tu fais
(et prie pour que personne ne vire par mégarde le " AND t2.id = t3.id(+) " en voulant supprimer un filtre)
 

et PostgreSQL, et DB2, et Access, et SQLite...
 

Je suis pas sur qu'il reste tant de versions < Oracle 8i dans les entreprises. Et l'autre choix possible à part changer de SGBD, c'est de procéder à une mise à jour

Bouge pas, je reviens demain    
 

surtout que devoir pondre des jointures where-based quand on connait les jointures join-based, c'est un peu trivial alors que l'inverse ne l'est pas...
 

 
les profs devraient réactualiser leurs supports de cours??? dans quel monde vivons nous...    
 

pour ma culture, il sert à quoi le (+)?
 

C'est pour la jointure externe, syntaxe Oracle, en T-SQL ce serait t2.id *= t3.id

je sais, je suis idéaliste

cf Fred999, c'est l'équivalent Oracle des Outer Join (là en l'occurence, le (+) étant placé sur la table de droite, c'est l'équivalent d'un RIGHT JOIN)
 

les OUTER JOIN existent sous T/SQL hein

Je sais, mais comme beaucoup de monde je n'ai JAMAIS été formé à cette syntaxe, et ne l'ai rencontrée que cette année (j'ai 10 ans d'xp et une formation en systèmes d'info )...
 
Par contre j'ai toujours fait gaffe à dissocier jointures et critères donc ça compense

Ah tu vois Harko, le problème soulevé par Fred999 (qui pour moi n'en est pas un), c'est que :
- beaucoup d'entreprises travaillent sous Oracle
- beaucoup de gens ne connaissent pas la norme ANSI, à moins de bosser avec SQL Server (ou mysql, les autres sgbd étant nettement moins répandus)
 
Ce qui peut se comprendre : quand je suis arrivé dans ma boite actuelle, on était en Oracle 7, donc syntaxe JOIN inconnue. Les différents développements se sont donc faits avec l'écriture traditionnelle des jointures dans la clause WHERE et les gens ne connaissaient que ça.
 
Au fil des migrations Oracle, personne n'a réécrit le code. Et pourquoi toucherait-on du code qui fonctionne ?
 
Personne (chefs de projets, dévs,...) n'a non plus été formé à changer sa manière d'écrire les conditions de jointure. Et pourquoi perdrait on du temps (précieux en entreprise) à réapprendre aux gens une autre manière d'écrire quand celle qu'ils connaissent ET maitrisent fonctionne parfaitement ?
 
Et je t'assure qu'on a des requêtes extrêmement lourdes (Société d'autoroutes), et qu'elles se lisent (relativement) bien.
Je n'ai également jamais rencontré de pb de produit cartésien (c'est pour ça que je te donne l'impression de le minimiser) en 9 ans de présence dans cette boite dû à une suppression malencontreuse d'un filtre.    
Tu auras compris aussi qu'on a une culture full Oracle, ceci explique celà...
 
Ca va, j'ai été soft  
 
Au passage, on n'a pas de nouvelles du p'tit gars qui demandait de valider ses requêtes alors qu'il y en a 2 sur 3 de fausses a priori