Discussion :

[martin_s]

Bonjour,

Je suis actuellement en train de développer une application Web en PHP/MySQL dont l'une des fonctionnalités est un annuaire basique (utilisateur et groupe).
J'ai pour cela créer 3 tables (1 user, 1 group et 1 pour relier les 2). Jusque là tout va bien tout fonctionne.

Aujourd'hui il n'y a qu'un seul utilisateur donc pas de problème. Par contre le but est d'avoir une interface multi-utilisateurs ou chaque utilisateur pourrait gérer son propre carnet d'adresses.

Je me pose donc les questions suivantes :
1. Dois-je utiliser les mêmes tables pour tous les utilisateurs ? Si oui, je suppose qu'il faut ajouter un ID ou autre par table pour savoir à quelle utilisateur logué appartient les données ?
2. Si non dois-je dupliquer les tables par utilisateur ? Ou Existe-t-il un système de table virtuel ou autres ?


Merci par avance pour vos réponses.

[-Rpass-]

un utilisateur peut avoir plusieurs groupes ? Si c'est le cas ton système avec 3 tables est bon. Dupliquer la table utilisateur ? Je suis pas sur de comprendre mais dupliquer une table n'est utile à priori que si tu as trop de données et que tu souhaites les répartir sur plusieurs tables. Pour ta table user tu peux rajouter un id unique afin de pouvoir facilement récupérer les donnés d'un utilisateur, tu peux aussi mettre des id pour tes groupes. De manière générale les ID sont très souvent utilisé il ne faut pas se priver, je sais pas si j'ai bien répondu à ta question

[BakSh0]

Bonjour,

Bien sûr que tu dois utiliser des ID uniques pour tes utilisateurs, en effet la question à se poser est : Est-ce qu'un utilisateur peut avoir plusieurs groupes ?

Si non tu peux ajouter l'ID du groupe directement dans la table utilisateurs et supprimer ta table de liaison.
Si oui, ta table de liaison comprendra notamment les 2 IDs de l'utilisateur et du groupe.

[martin_s]

Salut,

Merci pour vos réponses.

Bon je crois que je me suis mal exprimé...

En fait le système user et group fonctionne bien. J'ai effectivement utilisé des IDs pour lier les tables entres elles.

Mon problème est que je souhaite mettre en place un système multi-utilisateurs, où chaque utilisateur qui se connecte pourra gérer son propre carnet d'adresses.

Par exemple, le système comporte 3 utilisateurs qui se loguent :

• Utilisateur A
• Utilisateur B
• Utilisateur C

Chaque utilisateur à son propre carnet d'adresses (composé d’utilisateurs appartenant à n groupes):

• Utilisateur A
  
  
  

  • User 1
  • User 2
  • User 3
  • User n
• Utilisateur B
  
  
  

  • User 1
  • User 2
  • User 3
  • User n
• Utilisateur C
  
  
  

  • User 1
  • User 2
  • User 3
  • User n

Ma question était de savoir comment gérer l'étanchéité des données pour que chaque utilisateur (logué) puisse seulement manipuler les données de son carnet d'adresses.

En espérant avoir été plus clair

[-Rpass-]

Effectivement c'est un peu plus clair. Pour qu'un utilisateur puisse enregistrer et consulter un carnet d'adresse tu peux procéder de la même façon que pour les groupes. Tu crées une table contenant l'id de l'utilisateur et l'id de l'utilisateur lié à celui-ci(par le carnet d'adresse).
Il n'y a pas de difficultés majeures par contre si tu veux que l'utilisateur puisse modifier les données d'un utilisateur dans son carnet d'adresse et seulement pour son carnet et non pour toute l'application, alors effectivement il faut se creuser un peu plus la tête. Tu peux éventuellement créer une table carnet_adresse ou tu enregistres les modifications supplémentaires des users pour un carnet d'adresse donné...

[CinePhil]

Les indications données par -Rpass- sont bonnes mais je te conseille vivement de commencer par bien modéliser tes données.

Comme tu indiques que tu es novice, tu as peut-être besoin aussi d'un petit cours de modélisation.

[martin_s]

Salut,

Oui ça rejoins ce que je pensais, à savoir intégrer un userid dans chaque table afin d'être sûr que l'enregistrement correspond bien à celui des données l'utilisateur en cours.
C'est bien ça ?

Je suis d'accord CinePhil, avant de m'attaquer à la réalisation pure j'avais tout bien mis sur papier mais le cahier des charges à pas mal changé entre temps...

[CinePhil]

Commence par bien établir tes règles de gestion de données.