Problème d'organisation : plusieurs valeurs dans un champs mysql

[nuitn0ire]

Hello,

Pour faire simple, voilà un exemple :

J'ai une table user, dans cette table user, j'ai des champs classiques (login, password, groupe, etc..).

J'ai une autre table, la table groupe. Dans cette table, j'ai déclaré les groupes suivants (dans un champs groupe_name admettons : user, modo,admin,redacteur, etc..

si je veux déclarer un nouvel utilisateur, je remplis tous les champs et mon super script va aller lister le contenu de la table groupe, et là, je choisi le groupe dans lequel rajouter mon user. Très bien, ça marche.

Par contre, si je veux que mon user appartiennent à plusieurs groupes, je fais comment ? je veux dire, d'un point de vue mysql ??

Dans le champs groupe de la table user, je peux mettre plusieurs variables ? genre "user; redacteur" etc.. ? Ou il ne faut qu'une variable par champs et dans ce cas, comment je pourrais contourner ce problème ?

J'ai ce souci pour cet exemple là, mais il se trouve que dans d'autres tables, pour d'autres variables je rencontre ce même problème d'organisation.

[andry.aime]

Bonjour,
Tu dois utiliser une table d'association pour liéer les 2 tables groupe et user.

[nuitn0ire]

Envoyé par andry.aime

Bonjour,
Tu dois utiliser une table d'association pour liéer les 2 tables groupe et user.

J'ai relu mon premier message et j'ai apporté des corrections (c'était pas très clair), du coup je ne suis pas sûre que tu ai exactement répondu à ce que je cherche.

quoi qu'il en soit, si c'est bien ça, tu pourrais m'en dire plus ? en prenant mon exemple par exemple.

/edit : après moulte réflexion, je viens d'avoir une idée, mais ça ne me semble un peu tordu

Il s'agirait de créer une table choixgroupe dans laquelle j'aurais :

user_id
groupe_id

Et à chaque fois que je veux rajouter un user dans un groupe, je créée un enregistrement du genre :

alfred
user

ensuite,

alfred
redacteur

etc..

Cette table contiendrait en fait l'ensemble des appartenances user/groupes.

Mais ça me paraît quand même vachement lourd.. Que vaut cette solution ?

[andry.aime]

Les structures des tables doivent être un peu comme ça:

user(login,password,...);
groupe(groupeID,groupe_name);
userGroupe(login,groupeId);

[s.lennon]

Bonjour.

ça peut paraître lourd, mais c'est l'unique solution pour un lien "n-n" (un groupe contient plusieurs utilisateurs, un utilisateur appartient à plusieurs groupes). A chaque fois tu dois créer cette table "intermédiaire" qui contient les deux identifiants.

Tu peux regarder ce cours sur la modélisation :
http://laurent-audibert.developpez.c...rs-UML017.html

Bonne journée.

[nuitn0ire]

Rah oui, merci.

Je voudrais votre avis quand même au niveau de la rapidité de tout ça. A présent, je vais prendre un véritable exemple, et je suis en train de me poser la question de la lourdeur des requêtes.

Ce que je veux faire : un simple indexeur de petites annonces.

Pour ce faire, là j'ai 3 tables, dans ces tables, il y a des champs qui commencent par EXT_ , il s'agit de champs qui vont piocher dans une autre table : Par exemple dans tbl_users, le champs EXT_user_localisation_id va en réalité taper dans localisation_id qui est un champs de la table tbl_localisation.

Voici une partie de mon dico :

tbl_annonces
Commentaires sur la table: gestion des petites annonces

Champ Type Null Défaut Commentaires
annonce_id int(6) Oui NULL
EXT_annonce_user_id int(6) Oui NULL
annonce_titre varchar(300) Oui NULL
annonce_contenu varchar(10000) Oui NULL
annonce_date_creation datetime Oui NULL
annonce_date_modification datetime Oui NULL

tbl_localisation
Commentaires sur la table: correspondance ville / codes postaux

Champ Type Null Défaut Commentaires
localisation_id int(5) Oui NULL
localisation_ville_name varchar(30) Oui NULL
localisation_ville_cp varchar(6) Oui NULL
localisation_ville_departement varchar(30) Oui NULL
localisation_ville_insee int(6) Oui NULL

tbl_users
Commentaires sur la table: Table user, password, date de création

Champ Type Null Défaut Commentaires
user_id int(6) Oui NULL
user_login varchar(30) Oui NULL
user_password varchar(20) Oui NULL
user_creation_date datetime Oui NULL
user_modification_date datetime Oui NULL
user_desactivation_date datetime Oui NULL
EXT_user_localisation_id int(6) Oui NULL
user_mail varchar(60) Oui NULL
user_validation_code varchar(32) Oui NULL
user_activation int(1) Oui NULL
user_mod_id int(2) Oui NULL

Ma question est la suivante : N'est-ce pas trop lourd si je veux lister les annonces et dans ce listing faire ressortir par exemple le code postal du propriétaire de chaque annonce ?

Parcequ'il y aurait une requete qui irait chercher le user id du propriétaire de l'annonce, et par rapport à ce user_id, elle irait ensuite chercher l'id de la localisation du propriétaire et de là elle ressortirait le code postale.

Ça me parait un peu lourd comme requête vous trouvez pas ? Est-ce Mysql saura gérer ça sans trop tousser ou il vaudrait mieux que je mette le code postal de l'annonce directement en dur dans l'annonce elle même (plus rapide, mais moins propre à mon sens..) ?

[s.lennon]

(re) Bonjour.

Juste une petite remarque qui n'a pas grand chose à voir avec ta question : le code INSEE d'une ville est unique, tu pourrais le passer en identifiant de ta ville, à la place de localisation_id, ce qui allège un peu ta table.

Sinon, concernant tes requêtes, il existe des solutions pour accélérer leur traitement: un index par exemple. Pour alléger l'écriture de ta requête, tu as aussi les vues...

Globalement, je pense que ton modèle est bon (j'aurais juste sorti le département pour en faire une table à part entière, de façon à pouvoir par exemple rechercher toutes les annonces d'un département donné).

En espérant avoir pu t'aider, bonne soirée.

[edit] Concernant les performances de MySQL, j'y connais pas grand chose mais je pense que ça dépend en partie de la quantité de données.

[nuitn0ire]

Envoyé par s.lennon

Globalement, je pense que ton modèle est bon (j'aurais juste sorti le département pour en faire une table à part entière, de façon à pouvoir par exemple rechercher toutes les annonces d'un département donné)..

Ah oui, effectivement. En fait, je partais du principe que le lieu de l'annonce (dept, ville, cp) était propre à ce qui était indiqué dans le profil de l'user, mais l'annonce peut tout à fait porter sur un autre endroit, d'où j'ai refait ma table comme ceci :

Champ Type Null Défaut Commentaires
annonce_id int(6) Oui NULL
EXT_annonce_user_id int(6) Oui NULL
EXT_localisation_id int(6) Oui NULL
annonce_titre varchar(300) Oui NULL
annonce_contenu varchar(10000) Oui NULL
annonce_date_creation datetime Oui NULL
annonce_date_modification datetime Oui NULL

Sinon pour la partie insee, en fait je vais virer ça, je pensais pouvoir me servir du code insee pour resortir des infos sur google map et faire un truc un peu blingbling avec ça, mais au final je n'en ai pas trouvé d'utilisation, néanmoins ta remarque était effectivement pleine de bon sens.

merci

/edit : par ailleurs j'ai une autre question, toujours dans le modèle actuel, j'ai une table contenant les infos de mes utilisateurs. Cette table ne contient que les infos primordiales. Mais j'aimerais que mes utilisateurs aient un profile plus complet, avec tout genre d'info (ce qu'ils aiment, ce qu'ils font, métier etc..). Ma question est la suivante : Est-ce que j'intègre ces infos directement dans ma table users, ou est-ce que je rajoute une table profiles et je fais correspondre dans ma table users un lien vers la table profile pour chaque user.
Travailler de cette façon me permet de ne charger le profile qu'au besoin, mais en même temps est-ce que le gain de perf que je fais làdessus est conséquent ? Mieux ne vaudrait-il pas tout mettre dans une seule table ? Sachant que je vise dans un premier temps entre 10000 et 15000 inscrits.

[s.lennon]

Bonjour.

J'y connais pas des masses en matière de performances en fait :s Néanmoins, je doute que 2 tables si similaires soient une bonne solution.

J'aurai tendance à privilégier des choses du genre une table METIER, ou encore CENTRES D'INTERET, etc. Des tables qui seraient relativement figées (dans l'idée, on ne crée pas un métier tous les jours ^^) et liées à ta table USER grâce à une clé étrangère. Ce sont ces tables-là que tu irais interroger quand tu veux plus d'infos sur la personne...

Pour le département je sais pas si j'ai été claire : effectivement, le lieu de ton annonce peut ne pas être celui de ton utilisateur. Mais j'aurai même été plus loin en créant une table DEPARTEMENT que j'aurai liée à LOCALISATION.

Sinon, j'aurai aussi créé une table style CATEGORIE pour classer tes annonces et là aussi faciliter les recherches de l'utilisateur...

En espérant avoir répondu à ta question, bonne journée.

[nuitn0ire]

mhh, plus concretement , de ça :

tbl_localisation
Commentaires sur la table: correspondance ville / codes postaux

Champ Type Null Défaut Commentaires
localisation_id int(5) Oui NULL
localisation_ville_name varchar(30) Oui NULL
localisation_ville_cp varchar(6) Oui NULL
localisation_ville_departement varchar(30) Oui NULL

Tu serais passé à quoi ?

Parceque si je détache le département et que je le mets dans une autre table lié à la table localisation, à ce moment j'ai aussi tout intéret à détacher le code postal (ou carrément le supprimer en fin de compte.. parceque je pense qu'ils feront une recherche par Dept ou par Ville, mais pas par code postale..).

Si je suis ton raisonemment et le mien, ça donnerait :

tbl_localisation_villes
Commentaires sur la table: correspondance ville / codes postaux

Champ Type Null Défaut Commentaires
localisation_id int(5) Oui NULL
localisation_ville_name varchar(30) Oui NULL

tbl_localisation_dept
Commentaires sur la table: correspondance ville / codes postaux

Champ Type Null Défaut Commentaires
localisation_dept_dept_id int(5) Oui NULL
localisation_dept varchar(30) Oui NULL

Mais je comprendrais toujours pas l'intérêt

Dans ma version actuelle, je peux lister les 3 critères sur lesquels je veux faire ma recherche (ville, cp, département). Je comprends pas ce qui changerait en éclatant tout dans 2 tables différentes.

[s.lennon]

L'intérêt de sortir le département, c'est de faciliter ta recherche sur le département. Si tu le laisses tel quel, un utilisateur peut par exemple insérer le département "Charente", ou encore "charente" ou "CHARENTE", voire même y faire une faute "Charante"... Et quand tu lances une recherche, ça va poser des soucis ^^

En sortant le département, tu en fais une table figée. Quand la personne veut insérer une ville, elle sélectionne le département dans une liste, donc tout utilisateur sélectionnera "Charente" avec la même casse et le même orthographe.

Plus généralement, on a tendance à dire que tout ce qui peut être sélectionné via une liste déroulante devient une table à part. C'était un peu la même idée qui me faisait te suggérer une table "CATEGORIE D'ANNONCE".

En espérant avoir réussi à m'expliquer ^^

[nuitn0ire]

Envoyé par s.lennon

L'intérêt de sortir le département, c'est de faciliter ta recherche sur le département. Si tu le laisses tel quel, un utilisateur peut par exemple insérer le département "Charente", ou encore "charente" ou "CHARENTE", voire même y faire une faute "Charante"... Et quand tu lances une recherche, ça va poser des soucis ^^

En sortant le département, tu en fais une table figée. Quand la personne veut insérer une ville, elle sélectionne le département dans une liste, donc tout utilisateur sélectionnera "Charente" avec la même casse et le même orthographe.

Plus généralement, on a tendance à dire que tout ce qui peut être sélectionné via une liste déroulante devient une table à part. C'était un peu la même idée qui me faisait te suggérer une table "CATEGORIE D'ANNONCE".

En espérant avoir réussi à m'expliquer ^^

Oui, je comprends mieux.

En fait, j'avais fait cette table au départ plus pour qu'il y est une sorte de correspondance automatiques entre les villes, cp et depts.

Ce qu'il faudrait que je fasse, c'est une table dept, une table villes,mais que les clefs primaires de ces tables aient idéalement les même valeurs, comme ça je garde ma correspondance (si un user entre "Lyon", je saurai ressortir automatiquement le département correspondant dans sa fiche), et dans la table user, je n'aurai plus un lien vers une table localisation, mais vers 2 tables : celle qui contient le département et celle qui contient la ville.

Je ne suis encore pas passé au code php, mais je voudrais faire ceci :

Au départ, l'user n'a qu'un choix : la liste des départements, il le choisi, et ensuite une autre liste apparait : la liste des ville (du département précédemment choisi).
Et ça, je pouvais le faire avec ma table actuelle (un truc du genre SELECT villes FROM localisation WHERE departement = le-truc-séléctionné-dans-la-liste actuelle) et là, hop, j'avais l'id de ma localisation comprenant code postal, ville et département.

Mais par la suite, c'est vrai que si je voulais faire une recherche par ville ou département, c'était pas franchement possible facilement vu que je devais aller rechercher à quoi correspondait chaque localisation_id de chaque user et ça j'ai peur que ça tue ma table.. Meilleurs temps d'entrer directement en dur (à partir de ce que tu proposes) le département et la ville dans le profile, ce serait plus rapide.
Ce qui m'embête, c'est qu'avec 2 tables, je ne vois toujours pas comment je peux faire la correspondance entre villes et départements.. L'idée, c'est que l'utilisateur séléctionne son département et ensuite n'apparaisse dans la liste que les villes de ce département. Là il y aurait un ID unique par ville, et un ID unique par départements.. du coup quand je sélectionne le département, eh bien toutes les villes de france sortent dans la liste..

Tu pourrais me montrer comment tu ferais ton dico pour ce problème toi ?

[s.lennon]

Pour un département, tu peux avoir n villes (où n est un entier quelconque) ; pour une ville, tu n'as qu'un seul département, d'où un lien "1-n" entre les deux tables. Dans ce cas-là, c'est l'id du DEPARTEMENT qui migre vers la table VILLE.

Ce qui donne :

tbl_departement
numero_departement int(3)
nom_departement varchar

tbl_ville
id_ville int(5)
lien_departement int(3)
nom_ville varchar
codepostal_ville int

Avec :
- numero_departement qui est l'identifiant de la table DEPARTEMENT (qui du coup n'est pas un auto-incrément, mais ça ne pose aucun souci) ;
- id_ville l'identifiant de ta table VILLE (qui peut être un auto-incrément ou le code INSEE, sachant que si tu laisses un utilisateur créer une ville, il ne connait pas toujours le code INSEE donc ça peut compliquer les choses) ;
- lien_departement qui est en fait égal à numero_departement, qui est donc ta "clé étrangère" et permet de savoir à quel département appartient la ville ; tu peux lui donner le nom que tu veux (j'ai l'habitude de mettre le préfixe lien_ pour signaler une clé étrangère, mais ça dépend de chacun ^^) ; pour indiquer que lien_departement est une clé étrangère, après avoir créer tes deux tables, la requête est du style :

Code :

1
2
3
ALTER TABLE tbl_ville
ADD CONSTRAINT FOREIGN KEY (lien_departement) 
REFERENCES tbl_departement (numero_departement)

(à vérifier, je ne me rappelles plus exactement sous MySQL)

Après, au niveau du code PHP, tu utilises de l'Ajax pour que dès que l'utilisateur a sélectionné son département dans la liste, la liste suivante ne contiennent plus que les villes du département sélectionné (avec une requête du genre de celle que tu as donné)...

Bonne journée

PS : je risque de ne pas être dispo ce week-end, mais si tu as d'autres questions, hésites pas, je regarderai lundi.

[nuitn0ire]

Merci pour cette réponse détaillée

Du coup, dans le code ça doit faire ainsi :

je liste le contenu des département, je choisis le departement ($dept), ensuite je me réfère à la clef étrangère pour aller choper toutes les villes qui ont la même clef étrangère, je liste les villes, j'en séléctionne une ville ($ville), et là dans ma table user, j'aurais enregistrer la ville ET le département en dur. Si j'ai bien compris (désolé j'ai un peu de mal, manque de sommeil ;p), c'est comme ça que ça travail.

Admettons que j'ai bien compris.

il faut savoir que j'ai déjà la liste complète de toutes les villes de france, avec leur CP et leur département correspondant (dans un CVS de plusieurs mo que j'ai chargé dans Mysql). Le hic, c'est qu'il faudrait que je prenne actuellement chaque ville et que je rajoute manuellement la clef étrangère correspondant à chaque département :\

sinon pour indiquer qu'il s'agit d'un clef étrangère, je croyais que ça se faisait directement dans la requête SELECT (en fait c'est la première fois que j'utilise des clefs étrangères comme ça...), je pensais qu'il y avait une option dans phpmyadmin qui permettait de l'indiquer.

[s.lennon]

Bonsoir.

En fait, dans ta table USER, tu n'auras que le lien vers VILLE, qui te permettra ensuite de remonter vers DEPARTEMENT. Ta clé étrangère correspond toujours à l'identifiant de la table. Par exemple, si je veux le département d'un utilisateur :

Code :

1
2
3
4
SELECT nom_departement FROM departement 
JOIN ville ON numero_departement = lien_departement
JOIN user ON id_ville = lien_ville
WHERE id_user = 123

avec lien_ville basé sur le même principe que lien_departement dans la table USER.

Pour ton fichier avec les villes et départements, tu as plusieurs solutions. Tu peux par exemple remplir ta table département dans un premier temps avec le numéro de département comme id, puis avec un éditeur de texte tu remplaces tous les "Gironde" par "33", "Charente" par "16", etc. dans ton fichier de villes. J'dois même avoir le fichier avec département et villes qui traine quelque part...

Sinon, pour la requête de création de clé étrangère, j'avoue que ça fait un moment que je n'ai pas utilisé PhpMyAdmin, mais ça n'a rien à voir avec un SELECT. Une "clé étrangère", c'est comme une caractéristique de ton champ, ça se gère donc dès la création de ta BDD... Après quelques recherches sur ce merveilleux forum , j'ai trouvé ça, en espérant que ça t'aide.

Bon week-end.

[nuitn0ire]

Eh bien merci à toi, je vais tester tout ça prochainement