Bonjour jeunes gens !

J'ai un petit soucis quand je tape ma requête SQL pour un devoir et je commence vraiment à m'arracher les cheveux

Je vous explique :

J'ai cette consigne : lister les DIFFERENTES oeuvres peintes (titre de l'oeuvre) qui ont été exposées à Paris ainsi que la date de début d'exposition, classé par date de debut d'expo décroissant et numéro d'oeuvre croissant

J'ai ces tables :

J'ai fais cette requête :
SELECT titre_oeuvre, datedeb_expo from b.(SELECT titre_oeuvre, id_expo FROM a.(SELECT titre_oeuvre, id_oeuvre FROM oeuvre INNER JOIN peinture ON oeuvre.id_oeuvre = id_oeuvre_peinture) INNER JOIN exposer ON a.id_oeuvre = exposer.id_oeuvre) INNER JOIN exposition ON b.id_expo = exposition.id_expo WHERE ville_expo = "Paris"
ORDER BY datedeb_expo asc, id-oeuvre asc;

Mais ça cloche...

Auriez vous une solution à mon problème ?

Sans avoir de quoi tester, ca, ca a l'air de marcher:

SELECT e.dateDeb_expo, o.titre_oeuvre FROM exposition e, exposer e2, oeuvre o, peinture p
WHERE e.id_expo = e2.id_expo AND e2.id_oeuvre = o.id_oeuvre AND o.id_oeuvre = p.id_oeuvre_peinture
AND e.ville_expo = 'Paris'
ORDER BY e.dateDeb_expo DESC, p.id_oeuvre_peinture ASC

Salut godrik,

Effectivement ça a l'air de fonctionner même si j'aurais préféré utiliser des jointures ^^".

Je te remercie!

Le 31 octobre 2015 à 10:30:21 Spiritel a écrit :
Salut godrik,

Effectivement ça a l'air de fonctionner même si j'aurais préféré utiliser des jointures ^^".

Je te remercie!

WHERE e.id_expo = e2.id_expo AND e2.id_oeuvre = o.id_oeuvre AND o.id_oeuvre = p.id_oeuvre_peinture

ce sont des jointures

Remplace le WHERE par un INNER JOIN et le AND par un WHERE

Les WHERE pour faire le jointure c'est dégueulasse, c'est pas pythonique du tout

Pourquoi c'est degueulasse? L'optimiseur de requete fait probablement la meme chose a la fin. Sinon, il faut changer d'optimiseur de requete

Pour des raisons de lisibilité.

Une jointure c'est une spécification sur condition comme une autre, mais ça reste une manière de spécifier les données qu'on veut, c'est un peu entre le where et le from en ce sens et donc c'est plus lisible quand on fait effectivement la jointure entre le where et le from avec les opérateurs join

Et de plus ça permet de prendre l'habitude parce qu'il y a de cas de jointures plus exotiques ou c'est encore plus avatageux et y compris niveau optimisation

Merci beaucoup, j'ai réussi à faire ce que je voulais grâce à vous

Pour des raisons de lisibilité.

Une jointure c'est une spécification sur condition comme une autre, mais ça reste une manière de spécifier les données qu'on veut, c'est un peu entre le where et le from en ce sens et donc c'est plus lisible quand on fait effectivement la jointure entre le where et le from avec les opérateurs join

Heu non. N'importe qui qui ecrit du SQL doit comprendre l'equivalence entre jointure et produit cartesien + restriction. C'est meme la definition formelle de la jointure. En terme de lisibilite, j'ai separer les conditions de jointure des autres conditions par un retour a la ligne. Et de toute facon, on ecrit jamais de requete comme ca dans la vraie vie. Tu les ecris toujours avec des intermedaires symbolique pour trouver aider la lisibilite et modularise le code.

Et de plus ça permet de prendre l'habitude parce qu'il y a de cas de jointures plus exotiques ou c'est encore plus avatageux et y compris niveau optimisation

Non!

Si tu as besoin d'une jointure plus exotique, tu feras une jointure plus exotique. Mais bon, les jointure ce n'est jamais tres exotique pour commencer. La seule difference est ce que tu prends les champs NULL ou pas. et que tu l'exprime avec un INNER JOIN/FULL JOIN/whatever JOIN ou que tu l'exprime avec un produit cartesien et des restriction qui vont bien, ca ne change absolument rien. Les requetes sont equivalentes. Elles sont represente par des arbres d'expression equivalent. Et certainement le planificateur d'execution prendra l'arbre d'expression equivalent qui minimise le temps de calcul.

Le seul cas ou tu peux battre l'optimiseur et le planificateur c'est si tu sais quelquechose sur la requete et sur les donnees dans la base que le DBMS ne peut pas savoir. Souvent, des histoires de statistiques sur la requete que le DBMS ne garde pas en memoire parceque la requete n'est pas assez commune. Et dans ces cas la, tu veux probablement construire la requete de facon tres precise et desactiver l'optimiseur pour cette requete en particulier.