Chercher dans la communauté

Bonjour, Je me retrouve encore dans l'impasse aujourd'hui avec une requête imbriqué. Ma base est structuré de cette façon : Tables : messagerie messagerie_message_type messagerie_utilisateur_type Structure table messagerie : id (int) parent_id (int) sujet (varchar) contenu (text) lu (bool) message_type (int) expediteur_id (int) expediteur_type (int) destinataire_id (int) destinataire_type (int) date (timestamp) exemple : [ 'id' => 1, 'parent_id' => 0, 'sujet' => sujet test, 'contenu' => blablabla, 'lu' => 0, 'message_type => 2, 'expediteur_id' => 9, 'expediteur_type => 1, 'destinataire_id' => 5, 'destinataire_type' => 2, 'date' => 2015-07-29 ] Structure table messagerie_message_type : id (int) type (varchar) exemple : [ 1 => question, 2 => message, 3 => demande d'infos ] Structure table messagerie_utilisateur_type : id (int) type (varchar) exemple : [ 1 => utilisateur, 2 => entreprise, 3 => ... ] Relations entre les tables : messagerie.message_type = messagerie_message_type.id messagerie.expediteur_type = messagerie_utilisateur_type.id messagerie.destinataire_type = messagerie_utilisateur_type.id Je cherche à lister tous les messages qui concerne un utilisateur (expéditeur et destinataire donc). Ma requête : SELECT * FROM messagerie WHERE (expediteur_id = x AND expediteur_type = 1) OR (destinataire_id = x AND destinataire_type = 1) Je récupère de cette façon les id des expéditeurs et destinataires. J'aimerai appliquer un SELECT et faire une jointure différente selon chaque ligne retourné par la requête. Je ne sais pas si cela est possible. Je m'explique : Je souhaite dans la requête ci-dessus pouvoir récupérer le nom_entreprise ou le nom et prenom selon si l’expéditeur est un utilisateur ou une entreprise. Je ne peux pas faire une jointure normale car un utilisateur peut être à la fois un expéditeur sur un message et un destinataire sur un autre. Je peux faire une boucle sur les résultats de la requête ci-dessus pour arriver à mes fins mais je sais que faire une requête en bouclant sur une autre ce n'est pas le mieux. Si il y a des pros du SQL dans la salle merci de m'aider. A bientôt