Bonjour,  
 
J'ai deux tables :
 
personnes (idpers, nom_pers, prenom, projid, etc.)
projets(projid, nom_proj, type, directeur, etc.)
 
Je veux sortir la liste de toutes les personnes qui ne sont pas affectés sur les projets de type 'maintenance'.
 
Je voulais faire un except , jusqu'à ce que je trouve que ça n'existe pas sous sql2000.
Donc  je passe par 'not exists' , j'ai donc écrit  (en m'inspirant de l'aide microsoft):
 
select distinct nom_pers
 from personnes
 where not exists
(select * from projets
 where projets.proj_id = personnes.proj_id
 and projet_type  like '%maintenance%' ) ;
 
ça ne semble pas être ça puisqu'il me sort presqu'autant de noms que si je faisais une jointure classique select * from personnes, projet where projets.proj_id = personnes.proj_id ;
Et que surtout quand je vérifie sur certains noms ils sont quand meme affectés sur les projets maintenance.
 
J'ai besoin d'une lumière pour m'éclairer.
 
merci de m'aider  
 
un noob

 
Salut,  
 
select  
        personnes.nom_pers  
from  
        personnes  
where  
        (personnes.projid not in (select projets.projid from projets  
                                          where projet_type  like '%maintenance%'))
 
?

Bonjour et merci pour cette réponse ,  
 
Cette requête fonctionne mais j'ai le même problème, elle me sort des noms qui sont quand même affectés à des projets maintenance. Du coup j'ai presque autant de lignes de résultats que si je ne triais pas.
Quelqu'un sait d'où est ce que ça peut venir ?

Euh les noms que la requête sort sont des noms qui sont affectés à des projets maintenance ET d'autres projets ?

oui je viens de vérifier

Admettons que tu es un "Dupond Pierre" qui est affecté à 3 projets, tu as 3 entrées dans ta table personnes pour ce Dupond Pierre ?
 
Il ne devrait y avoir qu'une seule et unique entrée par personne .  
 
Ensuite une table de liaison idpers / projid ou je n'ai peut-etre pas compris.

tu as très bien compris. Et c'est ce qui m'a frappé quand j'ai commencé à travailler sur cette base de données.
Bon ben reste plus qu'a convaincre l'admin...
 
Merci quand même

ça vous amuse de foutre par terre votre serveur quand une simple jointure résoud le problème sans effort ?

SELECT per.*
FROM personnes per
LEFT OUTER JOIN projets pro ON pro.projid = per.projid AND pro.type = 'Maintenance'
WHERE pro.projid IS NULL

Ca ne résoudra pas son problème
 
Mais ce n'est pas grave.
 
 
 

Merci magicbuzz mais j'ai le même résultat qu'avant...

Moi c'était juste histoire de virer déjà cette sous-requête inutile

Ensuite, les noms des gens qui sont en double selon s'ils sont sur 1 ou n projets, y'a un souci de modélisation là... Parce que c'est total nawak. idpers doit être la PK de la table personnes (et nom_pers, prenome) à priori une clé alternative, tout du moins sans doublons réels, uniquement des homonymes), et si une personne peut travailler sur plusieurs projets, et un projet peut être efectué par plusieurs personnes, alors il faut une table de correspondance.

Finalement, voilà la solution au problème : (avec toujours une jointure, ça sert à rien de se lancer dans des sous-select inutiles)

SELECT per.nom_pers, per.prenom
FROM personnes per
LEFT OUTER JOIN projets pro ON pro.projid = per.projid AND pro.type = 'maintenance'
GROUP BY per.nom_pers, per.prenom
HAVING count(pro.projid) = 0

Vérification :

DROP TABLE personnes
go
DROP TABLE projets
go
 
CREATE TABLE projets
(
    projid numeric PRIMARY KEY,
    nom_proj varchar(20),
    type varchar(20),
    directeur varchar(20)
)
go
 
CREATE TABLE personnes
(
    idpers numeric, 
    nom_pers varchar(20), 
    prenom varchar(20), 
    projid numeric FOREIGN KEY REFERENCES projets(projid)
)
go
 
INSERT INTO projets VALUES (1, 'Projet 1', 'maintenance', 'Directeur');
INSERT INTO projets VALUES (2, 'Projet 2', 'maintenance', 'Directeur');
INSERT INTO projets VALUES (3, 'Projet 3', 'maintenance', 'Directeur');
INSERT INTO projets VALUES (4, 'Projet 4', 'nettoyage', 'Directeur');
INSERT INTO projets VALUES (5, 'Projet 5', 'nettoyage', 'Directeur');
INSERT INTO projets VALUES (6, 'Projet 6', 'nettoyage', 'Directeur');
 
INSERT INTO personnes VALUES (1, 'Dupond', 'Toto', 1);
INSERT INTO personnes VALUES (2, 'Dupond', 'Toto', 2);
INSERT INTO personnes VALUES (3, 'Durand', 'Titi', 3);
INSERT INTO personnes VALUES (4, 'Durand', 'Titi', 4);
INSERT INTO personnes VALUES (5, 'Dupuis', 'Tutu', 5);
INSERT INTO personnes VALUES (6, 'Dupuis', 'Tutu', 6);
INSERT INTO personnes VALUES (7, 'Dupuis', 'Tutu', NULL);
INSERT INTO personnes VALUES (8, 'Prout', 'Coin', NULL);
INSERT INTO personnes VALUES (7, 'Dupond', 'Toto', NULL);
INSERT INTO personnes VALUES (7, 'Durand', 'Titi', NULL);
 
SELECT per.nom_pers, per.prenom
FROM personnes per
LEFT OUTER JOIN projets pro ON pro.projid = per.projid AND pro.type = 'maintenance'
GROUP BY per.nom_pers, per.prenom
HAVING count(pro.projid) = 0

Je ne pense pas avoir oublié de cas

PS : Je sais pas trop d'où vient ce warning, mais à la base on s'en cogne, ça marche

Merciiiiiiiiiiii !
 
Ça marche  .
Une dernière question, est-ce qu'une mauvaise modélisation d'une base de données peut être source de problèmes de performance ?

Euh... Est-ce que si je mets des roues carrées à ma voiture je risque d'avoir des problèmes pour rouler ?

Non seulement niveau perfs tu y perds énormément (lire des données inutiles, non indexées) mais en plus en maintenance.

Mademoiselle "Céline Dupuis" se marie à monsieur "Mathieu Durand".

T'as l'air fin pour changer le nom de la demoiselle. Surtout si elle a un homonyme parfait dans la base déjà... Aucun critère pour les différencier, je dirais que t'es mal

Ok merci pour vos réponses.