Requète imbriquée

Bonjour,

Je rencontre un problème de liaison de deux tables:
j'ai un première table qui contient des véhicules VEHIC et une autre table qui contient les enregistrements planning de ces véhicules.
Je souhaite pour une période donnée récupérer tous les enregistrement planning. Mais le problème est que je n'ai pas les véhicules qui ne sont pas utilisés au planning...et il me les faut.

Afin d'être optimal, j'ai créé une jointure et traité le problème du planning. Je cherche une solution élégante et performante (client/serveur)qui me permette d'y intégrer les véhicules absents du planning.

Une première piste est d'utiliser une requète intégrée : mais pas très optimale.
Une deuxième piste est de créer une deuxième requète derrière et de compléter la première: pas terrible non plus !

Qu'en pensez-vous ?

Merci pour vos réponses.

Richard

Une simple requete sur la table VEHIC avec jointure externe gauche sur la table planning devrait suffire, non ?


---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Merci Casy

Genre:
Select
Planning.Id_Vehic
...
...
Vehic.Id_Vehic
...
...
From
Vehic Left outer join Planning on vehic.id_Vehic = planning.id_vehic
Where
planning.dateDebut >= pdatedebut and planning.dateFin <= pdatefin
Order by
...

Résultat : si les véhicules ne sont pas dans le planning ils n'apparaissent pas. Hors il me les faut, même à vide.

Comment faire ?

Il n'apparaissent pas à cause de la clause Where.

Pour qu'ils apparaissent, il faut rajouter le cas ou il n'y a pas de planning, c'est à dire ou Planning.dateDebut et Planning.dateFin sont nuls



---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Après essai le résultat est le même.

Si on paramètre avec une journée sans planification, il ne ramène rien.

En fait les dates ne sont pas null (si j'ai bien compris ?) mais l'enregistrement est absent dans le planning. Est ce que le Null = rubrique vide ?

Ok, je me suis un peu mélangé les pinceaux.
J'étais parti sur l'idée que les véhicules que tu ne vois pas n'avait pas du tout de planification. Or, ils ont bien des planifications mais en dehors de la plage souhaitée. Donc forcément ma requete ne marche pas.

Il faut effectivement des requetes imbriquées. La jointure se faisant ici, non pas sur la table planning, mais sur table temporaire ne contenant que les planifications dans la plage de date souhaité. D'ailleurs la jointure sera plutôt à ce moment là une externe droite :



Attention, les champs "plannings" dans la clause SELECT ne viennent plus de la table Planning, mais de la table temporaire P

En espérant que cette fois-ci, ça marche

---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Merci casy de venir bruler tes neurones avec moi
Excuses moi mais j'étais chez un client cet AM.

Voici le code que j'ai testé
SELECT
v.id_VEHIC AS id_VEHIC,
V.NBR_PLACE AS NBR_PLACE,
V.VehicActif AS VehicActif,
V.VehicAFF AS VehicAFF,
V.catVehic AS catVehic,
V.id_TY_VEHI AS id_TY_VEHI,
V.Cle_Rang AS Cle_Rang,
V.dateSup AS dateSup,
V.PLQ_NUM AS PLQ_NUM,
V.desig50 AS desig50,
P.PGCLEUNIK AS PGCLEUNIK,
P.date_debut AS date_debut,
P.Heure_Debut AS Heure_Debut,
P.date_fin AS date_fin,
P.HEURE_FIN AS HEURE_FIN,
P.Lib_planning AS Lib_planning,
P.lib_survol AS lib_survol,
P.Typ_Mission AS Typ_Mission,
P.Cli_Option AS Cli_Option,
P.Id_MISSION AS Id_MISSION,
P.id_VEHIC AS id_VEHIC,
P.Id_M_Vehic AS Id_M_Vehic,
P.IDLg_Mission AS IDLg_Mission,
P.IDINTTECH AS IDINTTECH
FROM
(SELECT * FROM PLANNING_VEHIC
WHERE (PLANNING_VEHIC.date_debut >= {pDateDebut} AND
PLANNING_VEHIC.date_fin <= {pDateFin})
) P
RIGHT OUTER JOIN VEHIC V ON P.id_VEHIC = V.id_VEHIC

ORDER BY
id_VEHIC ASC

et le résultat est identique: aucun enregistrement ne remonte quand je paramètre un jour sans enregistrement dans la table planning_vehic.

Pourrais tu m'expliquer la différence entre jointure gauche et droite: j'ai cru comprendre une différence de cardinalité L(1,0) et R(1,+).

Par rapport à ton code ta requète sur le planning me parait bonne, par contre la recherche des véhicules absents dans la table planning et présents dans la table vehicule semble poser un problème.
Est ce que l'utilisation de is not ne serait pas une solution peut être dans une autre sous requète concernant les véhicules ? Ce n'est pas très élégant...
Ou l'élimination d'une intersection ?

Merci

Je pense que ta requete génère une erreur sur la clause ORDER BY, le nom id_VEHIC est ambiguë.

En effet, dans ton résultat, tu as 2 champs (alias) dont le nom retourné est id_VEHIC, le moteur SQL ne doit pas savoir sur lequel faire le ORDER BY.

Soit tu donne à chaque champ un nom unique, soit dans la clause ORDER BY, tu précise de quelle table le champ vient : ORDER BY P.id_VEHIC


---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

Bonsoir,

J'ai supprimé la clause order by et je teste :

Si je teste sur un jour où il n'y a aucun enregistrement dans le planning, donc la requète devrait ramener au moins les véhicules: le résultat est "pas d'enregistrement"

Si je teste sur un jour où il y a des enregistrements, il généère une erreur de code sql sur <P> : pourquoi, je ne sais.

Dans tous les cas si j'ai bien compris ton code,le right outer join portant sur vehic ne peut me semble-t-il satisfaire la condition car elle n'existe pas, l'enregistrement côté planning étant absent. Peut être existe-t-il une clause absent, is not ??? unknown ???

Merci

Richard (je suis absent demain, je pourrai lire ta réponse mes pas la tester avant samedi matin)

Pour ce qui est des jointures, je te conseille de lire ce document. Il t'apportera, j'espère, quelques précisions quant à leur fonctionnements.

[ Lien ]


Pour ce qui est de ta requete, l'absence de résultat ne vient pas (pour le moment en tout cas) d'un problème de jointure, mais simplement du fait que ta requete ne s'execute pas car elle comporte une erreur.

D'après le message que tu rapporte, ton moteur de base de donnée ne semble pas comprendre la syntaxe utilisée pour donner l'alias P à la requete intermédiaire.
Cette syntaxe marche telle quelle sous SQLServer. Je ne connais pas ton SGBD, mais il faudrait vérifier la syntaxe qu'il attend concernant les alias de tables.


---- Sevyc64 (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #