Discussion :

[sliderman]

Bonjour,

Je voudrais savoir s'il existe en MySQL une structure de données arborescente. Je m'explique : une structure de données qui soit un peu à la sauce XML, comprenant un tableau (ou qqch sur lequel on peut boucler) de données (un peu comme deux noeud XML.

Par exemple, j'ai un utilisateur qui est dans un groupe (g2) qui est dans un groupe (g1) qui dépend d'un groupe (g0)...
Et que je puisse boucler avec un langage (PHP) sur cette structure de donnée (for, while ...)

[Gaara-Manga]

Par rapport à ton exemple, en faite on aurait 2 tables.


L'une contenant les type de transport(marin, terrestre, aérien...)

Et une autre avec les objets de chaque type de transport avec autant de paramètre que l'on souhaite.


Le lien entre les 2 serait assez basiques, ta table objet aurait juste une liaison avec ta table type_transport.

Après on peut aller loin je sais pas exactement ce que tu veux faire donc voila^^

[sliderman]

c'est juste un exemple, on peut aussi essayé d'expliquer cela avec des véhicules :
rv456 est une clio blio -> elle appartient à la table 'racine' vehicules, elle appartient à la table de second niveau (qui dépend directement de la table racine) voiture, elle appartient aussi à la table de troisième niveau (voiture à quatre portes), elle appartient ensuite à la table de cinquième niveau clio ....

enfait pour moi j'ai besoin de m'être en place un système d'utilisateurs avec des groupes, par exemple :
l'utilisateur root a tous les droits (ceux de tous les groupes)
l'utilisateur toto appartients au groupe users et members, donc il les privilèges de ces groupes ci
l'utilisateur tata appartients au groupe super-users, il a les privilèges d'un users mais aussi d'autres droits

[Gaara-Manga]

Pour faire ce genre de chose t'aurais alors

1 table Groupes
1 table Users

T'a table groupe aurait en partie comme champ (id, nom, droit)
Et t'a table user en partie (id, pseudo, etc...)

Seulement toi tu veux faire en sorte qu'un utilisateur puisse appartenir à plusieurs groupe.

Pour être plus technique, 1 groupe peut avoir plusieurs membre et 1 membre peut appartenir à plusieurs groupe.
On appel se genre de liaison, une liaison de type n, n.

Dans ce genre de liaison il te faut créer une 3ème table qui va lier les deux qui sera du genre :

UsersToGroup et qui contiendra (id_group, id_user)

Ainsi chaque appartenance d'un membre à un groupe se trouvera dans cette table.


Jsais pas si j'ai bien expliqué mais si t'as besoin de détails hésite pas

[sliderman]

enfait oui il est vrai que j'aurais bu choisir une CIM (relation type n,n), mais j'ai préférer faire autrement.

pourquoi, parce que puis je avoir un langage qui me permette de boucler sur toutes les 'n' occurrences de l'entité reprise, non je ne pense pas (je peux me tromper).

j'ai bien refléchis, je crois avoir trouver une solution :
je créer deux table, groups et users
dans la première, la Nested Set, j'insère l'id du groupe, l'id du groupe parent, l'id du group fils, et son nom
dans le seconde, je mets l'id de l'utilisateurs, son logine, son mot de passe et le nom du groupe

[Gaara-Manga]

C'est le principe même de l'arborescence^^

On peut faire comme sa également par contre, pas besoins de mettre et l'id du fils et du parent dans ta table groupe.

L'id du parent référence suffira

[sliderman]

j'ai pas bien compris ta réponse ?
c'est lequel le principe de l'arborescence ?
celui de la parcourir ?
parcourir, okay mais avec quoi ? quel langage ?

pourquoi l'id du fils ne serait pas la peine.
imagine que je veuille mettre en place une page qui me permette d'ajouter un groupe, je vais donc devoir savoir où le placer, je vais donc avoir des listes déroulantes qui m'indique les droits (en partant du droits le plus bas et en remontant il faut bien que j'ai l'id du fils)

[Gaara-Manga]

Le principe du parent et du fils que tu venait d'évoqué c'est sa le principe de l'arborescence.

Sinon nan t'a juste besoin de connaitre le parent pour faire une arborescence.
Pas la peine de connaitre le fils puisque ce même fils contiendra l'id du parent donc on sera automatiquement que c'est son fils.


Pour faire un exemple concrêt, Robert est le père de Gérard.

On sait que Robert est son père donc pas besoin de dire que Gérard est le fils de Roberts puisqu'on peut le déduire de la première informations.

[sliderman]

Pas la peine de connaitre le fils puisque ce même fils contiendra l'id du parent donc on sera automatiquement que c'est son fils.

forcément, mais bon ah ce qui parait cette structure de donnée (Nested Sets) est reconnu, je vais donc faire comme il préconise


peut être plus tard, si je n'ai pas besoin de l'id du fils, je l'effacerai


mais dans cette structure, on ne parle pas vraiement de fils mais plutôt de frère (gauche droite)
c'est une imitation du système père fils, mais ce n'en ai pas un vrai