Faire un select test sur deux tables non liées

Bonsoir,

je souhaiterais savoir si il serait possible de faire ceci :

- j'ai deux profils d'utilisateurs donc une table par profil avec des champs différents, sauf au niveau de l'adresse mail et du mot de passe qui sont deux champs communs à tous les profils (un "profil" correspondant à une "table").

Question : J'aimerais lorsqu'un utilisateur d'un profil A ou B se connecte, pouvoir vérifier son authentification en testant dans en une même requête ma table de profil A et ma table de profil B.

J'ai tenté cette requête, qui si personne n'existe, renvoie rien ok, mais si la personne qui se connecte correspond à un enregistrement du profil B par exemple, ça me rend le jeu du profil B qu'il me faut + un jeu du profil A, donc je me retrouve à ne plus savoir qui est le bon utilisateur authentifié, si il appartient au profil A ou au profil B.

Code:

---

SELECT pa.nom, pb.nom FROM profil_A as pa, profil_B as pb WHERE (pa.login=? AND pa.email=?) OR (pb.login=? AND pb.email=?)

---

Y a t-il une formulation de requête particulière ou une quelconque possibilité d'opérer pour tester plusieurs tables de profils et piocher le bon utilisateur qui se connecte, le tout en restant sur une unique requête?

Bonjour
Regarde du côté de UNION
UNION est utilisé pour combiner le résultat de plusieurs requêtes SELECT en un seul résultat.

bonjour,

Vous avez un probleme de modélisation.

Vous avez mélangé deux notions dans un même entité du coup vous vous retrouvez à devoir faire des requêtes complexe pour rien.

Il vous manque à minima une entité utilisateur qui serai associée à 1 ou n profil

Bonjour et merci pour vos solutions. En effet union correspondait à mes besoins ypcman.

D'un point de vue conceptuel, j'ai commencé par une autre approche de modélisation punkoff, mais j'avais une table utilisateurs avec un id_profil, qui renvoyait donc sur une table profils.

Le problème c'est que mes champs de la table profils n'allaient pas être les mêmes en typage et en contenu selon le profil et que je ne voulais pas créer X champs dont certains resteraient vides selon le profil.

Alors je suis entre 2. J'ai une autre possibilité d'inclure une autre table qui modéliserait chaque profil, et la 2e table ferait le lien entre les utilisateurs et la 3e.

Moi ce qui me dérangeait dans le fait de regrouper tous les utilisateurs dans une même table, c'est qu'ils sont très différents.

Mais après, je me trompe surement, et je ne choisis pas forcément la façon la plus optimisée, et il m'arrive souvent de changer tout un système quand il ne me convient plus. ;)

pensez à l'héritage.

Toutes les données communes identiques dans une table mère, et les données spécifiques dans les tables filles.

Ça facilitera les cas comme celui-ci, et vous permettra d'alléger certains traitements de doublons par exemple.