Ik ben bezig met het maken van een CMS/ledensysteem voor een vereniging. Aangezien de rechten van de gebruikers onderling verschillend zijn, werk ik met (gebruikers)groepen om de rechten te geven. De groep bepaalt de rechten.

Ik wil het systeem zo dynamisch mogelijk maken, en er komen zeer veel verschillende rechtensoorten (zoals 'artikel toevoegen' of 'pagina wijzigen').

Wat is de handigste manier om bij die groepen de rechten die ze krijgen op te slaan in MySQL?

Opties die ik zelf zag, maar niet echt perfect vond, waren:
1. Per recht een nieuwe rij aanmaken in MySQL (nadeel: gezien het feit dat er soms nieuwe rechten bijkomen, moet telkens het tabel aangepast worden)
2. één veld maken voor alle rechten, die hij scheidt met een | of ander teken: met explode/implode te maken/krijgen. Of dit, maar dan met serialize(PHP)
3. Een nieuw tabel maken met daarin de rijen 'gebruikersgroep (als verwijzing naar de groeepn), de rij 'recht' (bijv. 'artikel toevoegen') en de rij 'waarde' (0 voor nee, 1 voor ja). Dit wordt dan een ontzettend lang tabel met heel vaak dezelfde groepen, zelfde rechten (die weer voor andere groepen gelden. Dit dan met een SQL join.

Mijn vraag is dan ook:
Wat is het handigste systeem om de typen rechten op te slaan, en hierbij gemakkelijk nieuwe rechten-typen te kunnen toevoegen en wijzigen. Zo dynamisch mogelijk, want dit moet gebeuren in PHP zelf (je kan in de CMS wijzigen in het "register")
@ pgFrank (omdat alleen hij aangeeft waar de pk en fk liggen).
Als je jou systeem omgaat zetten in tabellen heeft dit als resultaat dat er meerdere rollen, rechten en users met de zelfde naam voor kunnen komen is dat echt wat je wil? (Bij users kan ik het me nog voorstellen, maar verder niet.)
meerdere rollen, rechten en users met de zelfde naam voor kunnen komen
Er zullen nog wel de nodige UNIQUE constraints aangebracht moeten worden, maar dat lijkt me eigenlijk niet meer dan logisch...
Boaz schreef op 26.04.2008 18:48
@ pgFrank (omdat alleen hij aangeeft waar de pk en fk liggen).
Als je jou systeem omgaat zetten in tabellen heeft dit als resultaat dat er meerdere rollen, rechten en users met de zelfde naam voor kunnen komen is dat echt wat je wil? (Bij users kan ik het me nog voorstellen, maar verder niet.)
Je wilt toch niet beweren dat jij een compleet systeem ziet in het schetsje dat hier wordt voorgeschoteld? Minstens 99% ontbreekt!

Desondanks is dit schetsje wel de basis van een goed systeem, die paar UNIQUE-constraints kun je zelf wel verzinnen. Mocht dat niet het geval zijn, dan is een database-applicatie al veel te hoog gegrepen, kun je beter eerst wat andere dingen gaan leren.

Ik probeer altijd zo weinig mogelijk tabellen te maken
Dat is een heel fout uitgangspunt, dan kun je beter het begrip database vergeten. Het lijkt mij handiger dat je een goed datamodel maakt, daar heb je veel meer aan. En wanneer dat 200 tabellen oplevert, dan heb je blijkbaar 200 tabellen nodig. Heb je er 25 nodig, heb je er 25 nodig.

Het aantal tabellen dat je nodig hebt, zegt helemaal niets, betekent niets en kun je niets aan afleiden. Wanneer jij 2 soorten data wilt opslaan en deze 2 soorten data hebben een meer-op-meer relatie, dan heb je al 3 tabellen nodig. Daar is geen ontkomen aan, tenzij jij jouw datamodel naar de bliksem helpt en graag veel bugs in je systeem wilt hebben...
Het was meer een vraag van bewustwording, niet speciaal voor jou, maar voor iedereen ook de TS, die uniques worden namelijk maar al te vaak vergeten.
Miloan schreef op 26.04.2008 23:29
Kijk ook eens naar optie 4: klikje();
Alleen bruikbaar in hele eenvoudige systemen, anders ben je zwaar de lul. Heb met dit soort grappen moeten werken, wordt je niet vrolijk van.
Ja, daar heb je ook een punt..

Reageren