[MySQL] Gebruikers- en groepenstructuur met meerdere niveaus

[BikkelZ]

Ik wil een flexibele userstructuur opzetten, en die opslaan in MySQL. Dus een user kan lid zijn van meerdere groepen en groepen kunnen zelf weer lid zijn van andere groepen.

Hoe ga ik dat in MySQL opzetten? En hoe trek ik het enigszins elegant weer uit de database?

Ik heb bedacht om een tabel met groepen te maken, en een is_lid_van achtige tabel. Dat is structureel misschien wel goed, maar ik moet net zolang losse queries blijven doen tot het laatste resultaat 0 is (heeft groep met id 658 nog in de tabel is_lid_van een koppeling naar een parent, doe dan een query of die parent weer in is_lid_van zit).

Of zit er gewoon helemaal finaal naast te denken?

[Orion84]

Wellicht kun je de boel wat vereenvoudigen en sterk optimaliseren door een vast/beperkt aantal lagen toe te staan. Dus bijv. Hoofdgroep, Subgroep en SubSubGroep ofzo.

[pietje63]

Inderdaad gewoon werken met koppeltabellen.

user
user_groep
groep_groep
groep

Voor elke groep die je vindt in user_groep moet je zoeken in groep_groep
Voor elke groep die je vindt in groep_groep moet je doorzoeken in groep_groep

Zo lastig lijkt het me niet.. Ik weet niet hoe vaak al deze gegevens wijzigen/ opgevraagd worden. Maar als het veel vaker bekeken wordt dan opgevraagd kun je er een cache tussen zetten

[KatirZan]

Orion84 schreef op maandag 24 juli 2006 @ 12:21:
Wellicht kun je de boel wat vereenvoudigen en sterk optimaliseren door een vast/beperkt aantal lagen toe te staan. Dus bijv. Hoofdgroep, Subgroep en SubSubGroep ofzo.

Of nog mooier, 1 subgroep voor alle "leden" en van daaruit opwerken naar meerdere hoofdgroepen die onderverdeeld zijn. Dit scheelt in programmeren

[Zeus]

Wat is het nut van die usergroepen die lid zijn van ander groepen?
Ben geen deskundige op dit gebied, maar ik geef vaak een level aan een gebruiker mee, bijvoorbeeld 10, 20 of 50, en aan de hand van dat nummer valt dan een gebruiker in een bepaalde groep. Wellicht te definieeren in een andere tabel.

[pietje63]

Althalus schreef op maandag 24 juli 2006 @ 12:32:
Wat is het nut van die usergroepen die lid zijn van ander groepen?
Ben geen deskundige op dit gebied, maar ik geef vaak een level aan een gebruiker mee, bijvoorbeeld 10, 20 of 50, en aan de hand van dat nummer valt dan een gebruiker in een bepaalde groep. Wellicht te definieeren in een andere tabel.

groep moderators
subgroep moderators devschuur
subsubgroep moderators programming

Zijn wel meer dingen te bedenken. Denk ook aan constructies bij (online) spelletjes waar je 10% van de score krijgt van de mensen die jij aanbrengte + 10%*10% van de mensen die zij weer aanbrengen, etc. (al weet ik niet of dit dan de juiste structuur is, maar ok).

[André]

Titelchange

[disjfa]

pietje63 schreef op maandag 24 juli 2006 @ 12:41:
[...]
groep moderators
subgroep moderators devschuur
subsubgroep moderators programming

Zijn wel meer dingen te bedenken. Denk ook aan constructies bij (online) spelletjes waar je 10% van de score krijgt van de mensen die jij aanbrengte + 10%*10% van de mensen die zij weer aanbrengen, etc. (al weet ik niet of dit dan de juiste structuur is, maar ok).

Daarvoor kan je net zo goed drie groepen voor aanmaken zoals het er al uitziet en elke groep een parent meegeven van elkaar zodat het fysiek er zo uit ziet. Dat scheelt iig wel behoorlijk veel queries.

Ik zou niet al te moeilijk doen met groep vs subgroepen. Dat kan je ook alleen visueel behouden en technisch gewoon user - user_groep - groep tabelletje. Moet je het alleen wel zelf bijhouden wat de groepen kunnen.

[DND_Roche]

gebruikers en groepen in 1 tabel;
relaties tussen gebruikers en groepen/groepen en groepen in 1 koppeltabel.

In Oracle kan je er de connect by prior clausule er op los laten.
Ik weet niet zeker of daar ook een variant van bestaat in MySQL; Google deed een beetje vaag hierover. Het hangt denk ik van je versie af of dit ondersteund wordt.

[BikkelZ]

DND_Roche schreef op maandag 24 juli 2006 @ 14:47:
gebruikers en groepen in 1 tabel;
relaties tussen gebruikers en groepen/groepen en groepen in 1 koppeltabel.

In Oracle kan je er de connect by prior clausule er op los laten.
Ik weet niet zeker of daar ook een variant van bestaat in MySQL; Google deed een beetje vaag hierover. Het hangt denk ik van je versie af of dit ondersteund wordt.

Misschien in 5, al vraag ik me af of dat wel 100% werkt zoals we zouden willen.....

Maar ik ben me heel even hier in aan het verdiepen:

http://www.vbmysql.com/ar...erarchical-data-in-mysql/

Dit ziet er heel erg interessant uit. Ik kwam er in ieder geval op uit doordat ik op die CONNECT BY PRIOR ben gaan zoeken, dus je wordt zeker bedankt!

---------------------------

Wel grappig dat die theoretische tree-logica hier weer terug komt.....het wordt wel ff spannend dat ik zorg dat de updates allemaal goed gaan, als ik dat verknal wordt het echt pezen bij veel records om alles goed te zetten.....

[ Voor 14% gewijzigd door BikkelZ op 24-07-2006 15:43 ]

[BikkelZ]

Nee dit is toch net niet wat ik zoek.....er moet namelijk meer dan één parent mogelijk zijn.....