Forum d'entraide PHPFrance

Salut a tout le monde !

Voila j'ai un probleme avec une requete que j'arrive pas a formuler...
Soit deux tables, incidents et user.
Il ya entre autre les champs 'id" et "déclaré par" dans incidents. "déclaré par" correspond a un nom de user.
Il ya dans user un champs "service", correspondant au service auquel est affecté le user en question ...

Je voudrais récupérer tout les id d'incidents dont le déclarant appartient au service X...

si j'y arrive pas je me fait

donc...
Merci !

Pas compliqué à priori, tu as fais des essais que tu pourrais nous montrer ?

Je déplace ce sujet dans "Base de données" au passage

Ah ben oui ça j'ai fait des essai...

Mais en fait ce sont ces essais qui m'ont conduit à ce forum...

J'ai essayé quelques truc avec inner join, j'ai aussi essayé de définir une variable($mavariable = Select nom user FROM user WHERE service) puis de l'insérer dans une seconde requete (SELECT id incident FROM incident WHERE signalé par = $mavariable) mais ça ne fonctionne pas vu que $mavariable correspond a un array...
Enfin voila quoi doit y avoir de faire ça plus simplement...j'espere

Oui ben le coup du INNER JOIN c'est une bonne idée

en français ta requête donne ça (en gros

):

Sélectionner les ID de incidents
reliés à user par declare_par = nom_user
et où service = 'service'

Donc INNER JOIN pour relier les deux tables entre elles, et un condition WHERE pour filtrer sur le service qu'on veut

Pourquoi se compliquer la tache avec des sous requêtes et des jointures, quand il suffit juste de lier le tout dans le where ?

SELECT i.id, i.chépaquoi, ..., u.id, u.nom, u.service // u. et i. permettent de dire de quelle table provient le champ
FROM user u, incident i // on retrouve ici u et i comme alias des tables, mais tu peux mettre ce que tu veux comme nom, voire utiliser directement user. et incident. :)
WHERE u.service = '$service' // uniquement pour les utilisateurs du service que tu recherches
AND u.nom = i.signale_par // et uniquement les incidents signalés par ces utilisateurs

GNNNNNH

Pourquoi se compliquer à donner des pistes, puisqu'il il est si simple de filer le code... ?

De plus :

Pourquoi se compliquer la tache avec des sous requêtes et des jointures,

Ok pour les sous-requêtes, mais pour les jointures, ça ne complique pas, au contraire.
On ne devrait réserver le WHERE qu'au filtrage, aux conditions, et faire les liens entre les tables grâce aux jointures

Car quand tu as 2-3 jointures, et 4-5 conditions, c'est bien plus lisible de séparer !

Du coup je file mon SQL aussi hein...

Code : Tout sélectionner

SELECT id FROM incidents i
INNER JOIN user u ON i.declare_par = u.nom
WHERE u.service = 'Service A'

ça devrait donner le même résultat que celle de Ryle, mais perso je trouve ça plus propre.

Une page intéressante sur les jointures : http://sql.developpez.com/sqlaz/jointures/

On y lit par exemple :

Dans la mesure du possible, utilisez toujours un opérateur de jointure normalisé Sql2 (mot clef JOIN).

En effet :
* Les jointures faites dans la clause WHERE (ancienne syntaxe de 1986 !) ne permettent pas de faire la distinction de prime abord entre ce qui relève du filtrage et ce qui relève de la jointure.
* Il est à priori absurde de vouloir filtrer dans le WHERE (ce qui restreint les données du résultat) et de voiloir "élargir" ce résultat par une jointure dans la même clause WHERE de filtrage.
* La lisibilité des requêtes est plus grande en utilisant la syntaxe à base de JOIN, en isolant ce qui est du filtrage et de la jointure, mais aussi en isolant avec clarté chaque condition de jointures entre chaque couples de table.
* L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.
* Lorsque l'on utilise l'ancienne syntaxe et que l'on supprime la clause WHERE a des fins de tests, le moteur SQL réalise le produit cartésiens des tables ce qui revient la plupart du temps à mettre à genoux le serveur !

Je suis entièrement d'accord avec ouckileou

* L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.

Non seulement les requetes sont extremement plus lisible, et le gain de performance est très loin d'être négligeable ...
Les principaux SGBDR ont un système d'optimisation des jointures qui ne fonctionne pas pour les jointures dans les WHERES

Franchement, c'est peut être pas simple à assimiler mais c'est vraiment mieux que les "fausses" jointures dans le where

plus d'info :
http://dev.mysql.com/doc/refman/5.1/en/ ... ation.html

Et en commençant à manipuler INNER JOIN même quand un lien dans le WHERE passerait, c'est le point de départ pour se familiariser avec les jointures externes.

Elles sont parfois indispensables et irremplaçables dans le WHERE (enfin je pense)

Donc ça ne fait pas de mal de commencer par une jointure interne simple pour s'habituer

raaah bah j'avais pas vu que tu avais posté avant, j'voulais juste expliquer comment marchait la requête en donnant un exemple adapté..
je l'fra pu

(enfin pu trop...)

Par contre pour les inner join, je pensais qu'au contraire, ils étaient moins performant et avaient d'avantage de contraintes... j'vais aller voir vos liens

hé hé si j'avais su que ça provoquerait une telle émulation...

En tout cas merci a tous si je trouve pas mon bonheur dans tout ça c'est que je suis vraiment irécupérable...

Pour l'instant je peux pas tester parcque mon cher serveur "odin" est en rad..

Mais vous battez pas hein, jvoudrais pas avoir une e-guerre sur la conscience... 8)
Ben ouais quoi
quand meme...
..

.

Oh mais on ne se bat pas

C'est une discussion sympathique et détendue, avec échange de points de vue

Après tout, c'est ça le but d'un forum
Une fois qu'on trouve ses erreurs de syntaxe tout seul et qu'on pose plus trop de questions, autant connaître les avis et les astuces des autres, c'est comme ça qu'on apprend des choses

"déclaré par" correspond a un nom de user.

Tu as le nom de l'utilisateur en clair ? il vaudrait mieux avoir un id, qui correspondra à l'id de l'utilisateur dans la table "user"

Parfaitement, pis du coup c'est comme ça que j'ai appris qu'il vaut mieux utiliser les inner join explicites pour optimiser l'exécution

Bon par contre d'après ce que j'ai compris, ça oblige à connaitre un minimum le contenu de sa base, parce qu'elle va du coup obligatoirement être interrogée en fonction de l'ordre des tables... faut donc un minimum de rigueur si on veut pas boucler 100 fois sur celle qui a 10.000 enregistrements

Le where avait l'avantage de laisser le sgbd gérer par défaut les priorités d'ordre (ce qui n'est pas toujours une bonne chose je vous l'accorde

) mais c'est effectivement plus logique et plus lisible de sortir les conditions de jointures des conditions de filtrage

Certains arguments ne sont vraiment pas justifiés, (le coup de "si on enlève le where pour faire un test on peut faire tomber le serveur" est un peu ridicule à mon gout

) mais ces deux derniers me suffisent.. vais coller du inner de partout maintenant

Forum d'entraide PHPFrance

en quete de Requette

en quete de Requette

Re: en quete de Requette