Bon vous allez me dire : mais qu'est-ce que c'est que ce titre a la noix !
Je vais prendre un exemple :
J'ai une table joueur, une table alliance.

Dans ma table joueur, j'ai le nom du joueur, et l'identifiant de son alliance.
Dans la table alliance, j'ai l'identifiant de l'alliance et le nom de l'alliance.

Je voudrais dans une même requête chopper le joueur et l'alliance, jusque la tout va bien :


(oui je sais Bernie, le nommage toussa toussa, d'ailleurs je veux bien des conseils la dessus parcque je pêche un peu).
Donc mon problème, c'est que des fois le joueur a une alliance, auquel cas je récupère bien tout, d'autres fois le joueur ne fais partie d'aucune alliance, auquel cas le champ `joueur`.`ID_alliance` est egal a NULL (la valeur NULL, pas la string "NULL" hein) et donc l'INNER JOIN merde et je n'ai pas le résultat.
J'ai ce problème partout dans mon site, et j'aimerais arriver a le résoudre autrement qu'en faisant plusieurs requêtes, parcque ca deviens un peu lourd au bout d'un moment.

J'ai oublié de préciser : `joueurs`.`ID_alliance` est une FOREIGN KEY qui pointe sur `alliance`.`ID_alliance`.

ça serait pas plutot OUTER JOIN qu'il faudrait ? Je sais le faire en Oracle (avec "+", mais en ansi99 j'ai un doute...

Un truc du genre :

Select a.joueur, a.nom, a.alliance, b.nom
from joueur a RIGHT OUTER JOIN alliance b on (b.alliance = a.alliance)
where a.alliance is null;

Je suis pas sur du tout, faut voir...

Sinon, la solution rustique :

select a.joueur, a.nom, a.alliance, b.nom
from joueur a, alliance b
where a.alliance = b.alliance
UNION
select a.joueur, a.nom, a.alliance, "***" from joueur a
where not exists (select b.alliance from alliance b where a.alliance = b.alliance)

EDIT : correction where a.alliance = b.alliance et pas where a.alliance ) b.alliance
Comme je dit précédemment, je suis pas du tout sur de ma solution "RIGHT OUTER JOIN", je suis plus habitué au standard Oracle (qui n'est pas standard d'ailleurs)

Merci !

Bernie : UNION c'est un peu porc, et j'aimerais eviter le WHERE quand il n'y a pas de condition particulière. Je voulais utiliser des JOIN parcque j'ai testé que c'était beaucoup (mais alors beaucoup) plus rapide sur de grosses bases de données que le WHERE, donc voila. Ptet que je me trompe hein, j'ai pas fait de recherche la dessus !

Bon, je me penche sur left et right join !

ben non, UNION c'est pas porc du tout, je vois pas pourquoi tu dis ça ? C'est du SQL...
Pour ce qui est du where, en effet si la table n'a pas un index efficace, ça peut faire un table scan et là, question perf, ben

Oui, penche toi sur les LEFT et RIGHT OUTER JOIN, parce que je maitrise mais alors pas du tout, faudrait que je me replonge dedans...

Bah si je peux eviter les unions, dans ce cas je pourrais faire un truc pour eviter les injections SQL. Niveau secu, c'est toujours ca de gagne.

pas compris, là ?

Bah dans ma classe de gestion des requetes, j'abandonne la requete si elle contiens un UNION.
Bien sur ca ne dispense pas des addslashes, mais ca peut servir au cas ou j'en oublierais !

pas compris pourquoi...

Parcque pour l'instant, l'union est le seul moyen que j'ai trouve pour faire de l'injection SQL.
Injection SQL : quelques exemples.
Suposont que on ai oublie de mettre un addslashes sur les parametres login et password d'un formulaire de connexion.
La requete est du type : SELECT `login` FROM `membre` WHERE `login`='$login' AND `password`=MD5('$password')

Supposons que tu rentre admin'-- comme login, et n'importe quoi en mot de passe :
Au final, tout ce qu'il y a derriere les -- est ignoree et tu es logue avec le compte admin. C'est encore plus grave si tu oublie les quotes dans la requete, parcque meme avec un addslashes ca peut passer. Ensuite, UNION. Tu utilise toto' UNION insert into `membre` (login, password, rang) values ('hacker', MD5('1337'), 'administrateur')-- comme login.
La tu a carrement ajoute un utilisateur avec les droits d'admin.
Bon bien sur, ce genre d'attaque reste rare, est inutile ou presque sur des petits sites a la mort moi le noeud comme j'utilise (quoique ptet pas d'autres), mais rien n'empeche de prendre de bonnes habitudes ^^

mais tout vient d'une erreur de codage. ça n'a rien à voir avec la clause where, l'union ou l'age du capitaine.
Même chose avec les overflow de buffer, ça empêche d'utiliser strcpy, ou memcpy ? Faut pas non plus exagérer, et se concentrer sur la qualité du code plutôt qu'édicter des ukases de ce type.

Et ce que tu appelles addslash ça serait pas plutôt back-slash ???

Heu, c'est une fonction php addslashes (ou quelque chose qui s'en rapproche), excuse moi ^^

Oui, ce sont des erreurs de codage, mais bon les failles de sécuritée viennent tout le temps de là non ?

oui, mais c'est pas une raison pour ne pas utiliser les fonctions qui vont bien ! C'est comme si je disais : j'utilise pas l'electricité, on peut s'électrocuter. Avec des précautions, on s'en sort. Ce conseil, c'est un de tes profs qui te l'a donné ? Parce que si oui, je sors mon dicton préféré : "mauvais prof, changer de prof"

Nop, j'ai pas de prof de PHP/SQL (enfin si Erel ^^).
Disons que j'utilise pas UNION, la seule manière de le retrouver dans une requête serait une injection SQL.
Je suis d'accord, c'est du bidouillage.

Le 02 juin 2006 - 10 h 31, Woofy a écrit : Nop, j'ai pas de prof de PHP/SQL (enfin si Erel ^^).

Et je précise que c'est pas moi qui lui ai dit de pas utiliser les fonctions à risques qui ne le sont pas si bien codées