8791 sujets

Développement web côté serveur, CMS

[Résolu] Union entre 2 tables differentes ?

Bonjour,

J'aurai besoin de votre aide je me retrouve dans une impasse Smiley decu .

j'ai une table pour les clients qui est comme ceci


CREATE TABLE IF NOT EXISTS `esf_clients` (
  `idclient` int(4) NOT NULL auto_increment,
  `societe` varchar(75) NOT NULL,
  `civilite` char(5) NOT NULL,
  `nom` varchar(35) NOT NULL,
  `prenom` varchar(35) NOT NULL,
  `adresse` varchar(155) NOT NULL,
  `adresse2` varchar(155) NOT NULL,
  `ville` varchar(75) NOT NULL,
  `codepostal` varchar(15) NOT NULL,
  `pays` varchar(55) NOT NULL,
  `tel` varchar(20) NOT NULL,
  `tel2` varchar(25) NOT NULL,
  `tel3` varchar(25) NOT NULL,
  `fax` varchar(20) NOT NULL,
  `email` varchar(155) NOT NULL,
  `siteweb` varchar(155) NOT NULL,
  `numsiret` varchar(25) NOT NULL,
  `codeape` varchar(10) NOT NULL,
  `numtvaintra` varchar(35) NOT NULL,
  `login` varchar(20) NOT NULL,
  `password` varchar(20) NOT NULL,
  `commentaire` text NOT NULL,
  `idgrp` int(4) NOT NULL,
  `iduser` int(6) NOT NULL,
  PRIMARY KEY  (`idclient`)
);


Et une autre table qui est pour l'admin celle ci


CREATE TABLE IF NOT EXISTS `esf_users` (
  `iduser` int(4) NOT NULL auto_increment,
  `nom` varchar(35) NOT NULL,
  `prenom` varchar(35) NOT NULL,
  `login` varchar(20) NOT NULL,
  `password` varchar(55) NOT NULL,
  `access` text NOT NULL,
  `droits` text NOT NULL,
  `ip_encours` varchar(55) NOT NULL,
  `etat` int(1) NOT NULL,
  PRIMARY KEY  (`iduser`)
);


et j'aurai voulu me servir que d'un formulaire pour la connexion des admins et des clients on ma parler d'UNION mais je n'y connait pas grand chose quelqu'un pourrais t'il m'éclairicir merci beaucoup Smiley cligne

Espérant d'avoir était le plus clair possible Smiley cligne
Modifié par subzeros (30 Jan 2010 - 21:43)
Salut,

subzeros a écrit :
et j'aurai voulu me servir que d'un formulaire pour la connexion des admins et des clients on ma parler d'UNION
Pour la révision des requêtes SQL voir http://sqlpro.developpez.com/

Alors effectivement faire une requête avec UNION peut fonctionner mais cela pose un problème de logique / normalisation. Puisqu'un login / password correspond à 1 et 1 seule personne tu devrais avoir une table authentification comportant un champ spécifiant s'il s'agit d'un client ou d'un admin et l'id associé dans la table correspondante. En gros sortir les champs login, password existants actuellement et créer une nouvelle table.

table authentification
* id_auth
* login
* pasword
* type_user (par exemple 0=client, 1=admin)
* id_associe (correspond à idclient ou à iduser en fonction de type_user)
Merci pour ta réponse j'ai donc fait


CREATE TABLE IF NOT EXISTS `esf_clients` (
  `idclient` int(4) NOT NULL AUTO_INCREMENT,
  `societe` varchar(75) NOT NULL,
  `civilite` char(5) NOT NULL,
  `nom` varchar(35) NOT NULL,
  `prenom` varchar(35) NOT NULL,
  `adresse` varchar(155) NOT NULL,
  `adresse2` varchar(155) NOT NULL,
  `ville` varchar(75) NOT NULL,
  `codepostal` varchar(15) NOT NULL,
  `pays` varchar(55) NOT NULL,
  `tel` varchar(20) NOT NULL,
  `tel2` varchar(25) NOT NULL,
  `tel3` varchar(25) NOT NULL,
  `fax` varchar(20) NOT NULL,
  `email` varchar(155) NOT NULL,
  `siteweb` varchar(155) NOT NULL,
  `numsiret` varchar(25) NOT NULL,
  `codeape` varchar(10) NOT NULL,
  `numtvaintra` varchar(35) NOT NULL,
  `login` varchar(20) NOT NULL,
  `password` varchar(20) NOT NULL,
  `commentaire` text NOT NULL,
  `idgrp` int(4) NOT NULL,
  `inscription` int(11) NOT NULL,
  `modification` int(11) NOT NULL,
  `access` int(1) NOT NULL,
  PRIMARY KEY (`idclient`)
);


Et la table esf_users je l'ai enlever et j'ai ajouter l'admin dans la table que j'ai garder et j'ai ajouter la colonne access donc 0 pour client et 1 pour admin par contre je ne comprend pas pour id_associe Smiley decu désoler
Modifié par subzeros (27 Jan 2010 - 20:35)
Je te suggérais de supprimer les champs login et password de tes 2 tables et de créer la nouvelle table authentification.

A la création d'un client tu fais un INSERT dans ta table esf_clients ET un INSERT dans ta table authentification avec les login/password saisis, type_user = 0 et id_associe = idclient qui vient d'être récupéré (utilisation de mysql_insert_id).

Pour la création d'un admin tu fais tout pareil avec type_user = 1 et id_associe = iduser.

Pour la vérification lors d'une connexion tu ne vérifies l'existence du couple login/password que dans la table authentification : si l'enregistrement existe type_user te permet de savoir s'il s'agit d'un client ou d'un admin (et dans quelle table chercher) et l'id_associe correspond soit à idclient soit à iduser.
Modifié par Heyoan (27 Jan 2010 - 20:36)
Ok donc voila se que sa peut donner


CREATE TABLE IF NOT EXISTS `esf_clients` ( 
  `idclient` int(4) NOT NULL auto_increment, 
  `societe` varchar(75) NOT NULL, 
  `civilite` char(5) NOT NULL, 
  `nom` varchar(35) NOT NULL, 
  `prenom` varchar(35) NOT NULL, 
  `adresse` varchar(155) NOT NULL, 
  `adresse2` varchar(155) NOT NULL, 
  `ville` varchar(75) NOT NULL, 
  `codepostal` varchar(15) NOT NULL, 
  `pays` varchar(55) NOT NULL, 
  `tel` varchar(20) NOT NULL, 
  `tel2` varchar(25) NOT NULL, 
  `tel3` varchar(25) NOT NULL, 
  `fax` varchar(20) NOT NULL, 
  `email` varchar(155) NOT NULL, 
  `siteweb` varchar(155) NOT NULL, 
  `numsiret` varchar(25) NOT NULL, 
  `codeape` varchar(10) NOT NULL, 
  `numtvaintra` varchar(35) NOT NULL, 
  `commentaire` text NOT NULL, 
  `idgrp` int(4) NOT NULL, 
  `iduser` int(6) NOT NULL, 
  PRIMARY KEY  (`idclient`) 
); 

CREATE TABLE IF NOT EXISTS `esf_users` ( 
  `iduser` int(4) NOT NULL auto_increment, 
  `nom` varchar(35) NOT NULL, 
  `prenom` varchar(35) NOT NULL, 
  `access` text NOT NULL, 
  `droits` text NOT NULL, 
  `ip_encours` varchar(55) NOT NULL, 
  `etat` int(1) NOT NULL, 
  PRIMARY KEY  (`iduser`) 
); 

CREATE TABLE IF NOT EXISTS `authentification` (
	`id_auth` int(4) NOT NULL auto_increment, 
	`login` varchar(20) NOT NULL, 
	`password` varchar(55) NOT NULL,
	`type_user` int(1) NOT NULL,
	`id_associe` int(4) NOT NULL,
);


Si j'ai plusieurs admin merci beaucoup pour ton aide parce que sa se fait rare.


$r = mysql_query("SELECT login,password,type_user,id_associe FROM `authentification` where login='".addslashes($login)."' and password='".addslashes($password)."';") or die(mysql_error());
if (mysql_num_rows($r)==0)
{
$_GET["msgr"] = "Erreur : Veuillez vérifier vos identifiants";
}
else
{
/* Si le pseudo existe on récupère les infos */
$id_associe = mysql_result($r,0,"id_associe");
$login = mysql_result($r,0,"login");
$password = mysql_result($r,0,"password");
$type_user = mysql_result($r,0,"type_user");

/* Le client est connecté, on crée les variables SESSION */
$_SESSION["ESFPRIVATE"]["id_associe"] = $id_associe;
$_SESSION["ESFPRIVATE"]["login"] = $login;
$_SESSION["ESFPRIVATE"]["password"] = md5($password);
$_SESSION["ESFPRIVATE"]["type_user"] = $type_user;
}


Se qui me pose problème c'est comment savoir si c'est l'id d'un admin ou d'un client ?
Modifié par subzeros (27 Jan 2010 - 22:15)
Tout d'abord quelques remarques :
* pourquoi faire des mysql_result plutôt qu'un mysql_fetch_assoc (ou mysql_fetch_array ou mysql_fetch_row) ?
* l'usage des majuscules pour un nom de variable est en général réservé à des constantes ce qui n'est pas le cas de $_SESSION["ESFPRIVATE"].

subzeros a écrit :
Se qui me pose problème c'est comment savoir si c'est l'id d'un admin ou d'un client ?
Bon... ce n'est pas la première fois que ça m'arrive mais j'ai un peu l'impression de parler créole ! Smiley langue

il suffit de mettre type_user = 0 pour un client et type_user = 1 pour un admin au moment de l'INSERT.
Modifié par Heyoan (28 Jan 2010 - 01:58)
Pourquoi ne pas utiliser le type enum pour type_user ? Ce serait plus simple qu'une correspondance uniquement numérique.
type_user enum('Admin', 'Client')

En plus ça permet des choses sympathiques avec la POO et PDO...
Effectivement sa serai plus sympa par contre j'ai du mettre résolu trop vite je cherche a différencier une session admin et une session utilisateur vu que les admins et utilisateurs se connecte sur le même formulaire.
Modifié par subzeros (29 Jan 2010 - 10:44)
QuentinC a écrit :
Pourquoi ne pas utiliser le type enum pour type_user ? Ce serait plus simple qu'une correspondance uniquement numérique.
Parce que en l'état il n'y avait que 2 types d'utilisateurs possibles et que à partir de 3 j'aurais plutôt suggéré une nouvelle table type_utilisateur avec clef étrangère dans authentification. Smiley cligne

@subzeros > toujours la même réponse : avec la variable $_SESSION['type_user'] tu peux savoir n'importe où quel est le type d'utilisateur en cours.
a écrit :
Parce que en l'état il n'y avait que 2 types d'utilisateurs possibles et que à partir de 3 j'aurais plutôt suggéré une nouvelle table type_utilisateur avec clef étrangère dans authentification.

Je vois pas trop l'utilité d'une table satellite et d'une jointure supplémentaire pour 3 ou 4 types d'utilisateurs seulement, types qui n'ont vraisemblablement pas vocation à être changeables au cours du temps (ou que exceptionnellement)
J'ai l'impression que faire une jointure pour ça, ça me paraît payer cher pour pas grand chose, franchement. ET je doute fortement qu'une enum même avec une dizaine de choix soit plus lente...

Quels seraient les avantages, selon toi, à utiliser une table supplémentaire plutôt qu'une enum, dans ce cas ?
C'est effectivement pas indispensable mais d'un point de vue normalisation c'est quand même plus propre (et pi ça évite que M'sieur Merise se retourne dans sa tombe ! Smiley lol )
a écrit :
C'est effectivement pas indispensable mais d'un point de vue normalisation c'est quand même plus propre (et pi ça évite que M'sieur Merise se retourne dans sa tombe !

Oui, bon, à ce moment là les enum et les set n'auraient jamais dû être inventés puisqu'ils sont toujours remplaçables par des relations classiques.
Bref, pour moi ce n'est pas un argument valable. Priorité aux performances.
QuentinC a écrit :
Oui, bon, à ce moment là les enum et les set n'auraient jamais dû être inventés
Eh bien personnellement je n'ai jamais rencontré un cas où le type SET m'ait semblé approprié et pour ce qui est du type ENUM je ne m'en sers que lorsque je suis absolument sûr que les valeurs possibles ne changeront pas au fil du temps (comme par exemple 'OUI', 'NON' / 'Monsieur', 'Madame', 'Mademoiselle', et ce genre de choses).

Parmi les raisons de ce choix :
* j'ai vu bien souvent des analyses "définitives" qui étaient remises en questions quelques années plus tard et qu'il est bien plus facile de rajouter un enregistrement dans une table que d'en modifier la structure (pour peu que la partie back office ait été prévue dans ce sens il n'y a même pas besoin d'un informaticien et un simple utilisateur peut le faire).
* personnellement ma priorité n'est pas la performance (assez négligeable dans le cas d'un ENUM comparé à une jointure sur une clef primaire) mais la modularité.
* d'une manière générale j'essaie toujours de rester au plus près de la normalisation puisqu'en pratique ça ne peut que simplifier la vie... même s'il existe quelques exceptions. Smiley murf
Sujet clos
Aller à