Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
dans la requete qui suit je n'obtiens aucun résultat alors que
je souhaiterais en avoir (lol)
select nro_equipement, designation, id_equipement
from equipements where datemaintenance + (periodicite || unite_periode)::interval
between '2011/04/01' and '2011/04/05'
and id_equipement not in (select id_equipement from entete_ot where date_validation is null)
si je décompose : la requete
select id_equipement from entete_ot where date_validation is null
me ramene une série d'enregistrement contenant des dates de validation à null
cette requete ci :
select nro_equipement, designation, id_equipement
from equipements where datemaintenance + (periodicite || unite_periode)::interval
between '2011/04/01' and '2011/04/05'
me ramene une série d'enregistrement contenue dans une période;
la totalité des ses enregistrements ne se trouve effectivement
pas la requete d'exclusion (celle du haut), il ne doivent pas l'etre
MAIS pour autant, ma requete combinée reste vide (sans erreur)
pourquoi ?
merci pour votre aide
Hors ligne
Aucune idée. Si on suit la logique, vous avez raison, il devrait y avoir les résultats. Mais si PostgreSQL ne renvoit rien, je pense que vous vous êtes trompés quelque part dans votre explication.
Guillaume.
Hors ligne
Un NOT IN avec une sous requête retournant des NULL ne donne jamais rien....
C'est un grand classique du langage SQL !
Démonstration :
SELECT 1 AS C
WHERE 2 NOT IN (3, NULL);Résultat vide... Alors que :
SELECT 1 AS C
WHERE 3 IN (3, NULL)Donne 1.
Bref, apprenez SQL, mon livre comme mon site Web peuvent vous y aider !
A +
Dernière modification par SQLpro (28/04/2011 18:29:15)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Personne n'a dit dans la discussion qu'id_equipement est à null, même si c'est une possibilité. Merci de lire correctement les posts avant d'y répondre. Et d'essayer, comme déjà demandé, de répondre de manière moins arrogante.
Par exemple:
«N'auriez vous pas des id_equipement à NULL dans la sous requête ? Si oui, …»
Quelques mots sur la logique ternaire auraient aussi été un plus, histoire d'expliquer pourquoi le NOT IN a ce comportement, plutôt que de recommander à l'interlocuteur d'apprendre tout SQL avant de revenir poser une question.
Bref, ici, on essaye d'aider les utilisateurs. C'est le principe de ce forum. Le but n'est pas forcément de vendre un livre ou d'assurer son autopromotion à chaque post, ni de rabaisser l'interlocuteur systématiquement. Cela devient pénible de vous le rappeler une fois toutes les 3 contributions.
Marc.
Hors ligne
Entièrement d'accord avec Marc.
Guillaume.
Hors ligne
Bonsoir,
d'autant que ce n'est surement pas la meilleure façon de faire sa promo (trop voyant, trop arrogant à mon sens) et c'est d'autant plus dommage que les interventions de SQLprosont souvent intéressantes (comme son site, voyez, je suis pas racunier, je fais de la pub) . Il manque juste un peu de forme.
C'est cette petite phrase
Bref, apprenez SQL, mon livre comme mon site Web peuvent vous y aider !
qui gâche tout. Un peu trop sèche à mon gout.
Beaucoup ici, dont moi, sont là pour s'améliorer en Postgresql comme en SQL (et en orthographe, mais c'est un autre débat).
Cordialement
Hors ligne
Merci à tous pour vos réations.
si l'un d'entre vous a écrit un livre sur l'humilité,
SQLPro (meme le pseudo est..:-) devra le lire.
Cela, n'enleve rien à la qualité de sa remarque.
que je vais bien analyser.
Quoi que... sur ce coup là, Marc à parfaitement raison.
il a mal lu le post.
ma liste d'id_equipement existe bien
select id_equipement from entete_ot where date_validation is null;
on filtre seulement ceux dont le champs date_validation est à null
Bref d'un point de vu général, un forum est à destination de tous
si l'on devait être expert en SQL, plus personne ne poserais de question.
j'invite SQLPRO à m'aider à résoudre le probleme
en reprenant la requete exposée.
Hors ligne
unisol, pour en finir avec la remarque de sqlpro, histoire d'être sûr que ce n'est pas ça (ça pourrait très bien être effectivement ce qu'il suggère):
la liste d'id_equipement existe bien, mais la question est de savoir si il y a une valeur d'id_equipement dans la liste qui est null.
Si oui, le NOT IN ne va effectivement rien ramener. La raison est simple: NULL, ça veut dire «je ne sais pas ce que vaut la valeur», en SQL. Donc, si il y a une valeur à NULL, et qu'avec un NOT IN on demande à PostgreSQL (ou à n'importe quel SGBD qui fait parle SQL d'ailleurs) de vérifier que la valeur cherchée n'est pas dans la liste, il ne peut pas le garantir: NULL est «valeur inconnue». Il considère donc que le test n'est pas vrai. Donc faux. Et donc ne retourne rien.
Marc.
Hors ligne
tout à fait exact d'ou le rajout de l'exclusion des valeurs pouvant être à Null
Hors ligne
j'ai regardé avec attention ce SQLPRO a voulu dire.
créer une liste sans enregistrements à Null.
En effet (marc l'a dit) la liste peut contenir entre autres des id_equipement qui sont Null
voici la requete qui marche
select nro_equipement, designation, id_equipement
from equipements where datemaintenance
between '2010/01/01' and '2010/04/05'
and equipements.id_equipement not in
(Select entete_ot.id_equipement from entete_ot where date_validation is null and id_equipement is not null)
la derniere partie de la requete exclut des resultats pouvant êtres Null
Hors ligne
select id_equipement from entete_ot where date_validation is null;
On filtre sur date_validation. C'est la valeur de id_equipement qui nous importe: celle là ne doit pas être null non plus.
Marc.
Hors ligne
les 2 dans mon cas.
date_validation en premier cas c'est sur elle que mon raisonnement algorithmique tient:
je cherche à savoir si un ordre de travail est encore ouvert (donc sa date de validation est à null)
et enfin et ç'est là l'objet du dilem
exclure les id_equipement à null car il "derange" la clause NOT IN
Hors ligne
Oui, les deux doivent être not null. Sinon le NOT IN ne marchera pas. Essayez donc en rajoutant dans la clause where de la sous-requête que les id_equipement ne doivent pas être NULL. À moins que ça soit déjà fait et que je n'aie pas compris votre dernier post.
Marc.
Hors ligne
la sous requete qui marche
(Select entete_ot.id_equipement from entete_ot where date_validation is null and id_equipement is not null)
Hors ligne
Ok. C'était donc bien ça le problème.
Marc.
Hors ligne
Hors ligne
Bref, comme vous l'avez constaté, c'était bien l'erreur que j'ai pointé... Mais il n'est pas si simple de traiter tous les cas... Comme je poste à peu près 50 fois par jour sur différents forums :
En france :
http://www.developpez.net/forums/f4/bases-donnees/ (dont ceux sur PG),
http://social.msdn.microsoft.com/Forums … fr/threads
http://social.msdn.microsoft.com/Forums … fr/threads
forum.phpfrance.com/sql-bases-donnees/
mais aussi à l'étranger...
Il ne m'est pas possible d'être toujours très explicite, d'où le renvoi vers d'autres articles, lieux, ouvrages...
En sus de cela il me faut travailler !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Si vous n'avez pas le temps de poster correctement ici, personne ne vous y oblige. Si vous postez, vous vous conformez à nos usages. À savoir respecter vos interlocuteurs.
Marc.
Hors ligne
je dois avoir un livre auquel vous avez participé.
je renvoi vers le lien de votre page : http://sqlpro.developpez.com/
lisez le bas, la derniere ligne.
Copyright © 2002 Frédéric Brouard. Aucune reproduction, même partielle....
Hors ligne
Pages : 1