Tijden veranderen
Ontwerpen usermanagement
Pagina: « vorige 1 2 3 4 5 volgende »
Gewijzigd op 03/07/2012 15:35:18 door Wouter J
Write Down op 03/07/2012 15:25:19:
Daar ben ik het niet mee eens. Waarom zou je het niet splitsen? Dit verhoogt naar mijn mening de flexibiliteit. Stel morgen maak ik een applicatie die maar een paar permissie instellingen kent. Overmorgen maak ik een totaal andere applicatie met meer complexe permissies. De 'functie' gebruiker is in beide applicaties hetzelfde, de permissies niet.
als ik een nieuwe applicatie schrijf, gebruik ik een nieuwe database. verder hoeft een database niet flexibel te zijn. een goede database is niet heel flexibel. normaliseren tot de max, en met queries de gegevens uitlezen, en ook meteen bewerken. lees ook eens deze tutorial. is bovengenoemde relatie een veel op veel, of veel op 1 relatie? nee, een 1 op 1. in mijn opzicht is het dan juist fout om die in een aparte tabel te zetten.
wanneer je zo gaat indelen om makkelijk uit te kunnen lezen, ben je fout bezig. databases zijn niet leuk, en zijn niet makkelijk. is dat wel het geval, moet je je achter je oren gaan krabben. de tabellen zijn maar het halve werk, de queries de andere helft. dat wordt vaak onderschat.
In dit geval, beschouw jij dit als onzinnig. Ik vind dit echter wel zinnig. Hierover kunnen we natuurlijk uren discussiëren. Ik ben er vrij zeker van dat ik jouw mening niet zal kan veranderen, en eerlijk gezegd, jij de mijne ook niet :-). En dat is goed zo!
Moest ik nou overgaan naar een model met verschillende groepen (en dus bijhorende permissies), hoe zou jouw model er dan uitzien? (Want dit ben ik eigenlijk wel van plan.)
Ga je dan een tabel maken met groepen en daarin de permissies stoppen? Ga je ondanks die groep nog steeds alles bij een gebruiker bijhouden?
Gewijzigd op 03/07/2012 15:58:09 door Write Down
hoe bedoel je precies met groepen? dat een persoon tot een bepaalde groep hoort? dan heb je toch precies hetzelfde als nu.
of bedoel je dat een persoon tot meerdere groepen kan horen? dan veranderd het verhaal. de relatie veranderd dan namelijk van een 1 op 1 naar een 1 op veel. en ja, dan heb je een nieuwe tabel nodig ja. dan zou je gelijk hebben.
Wat doe je in de volgende situatie: een billing applicatie. Je vraag aan een incasso bureau jou te helpen. Ga je dan enkel voor dat bureau een aparte groep gaan maken? Zou ik persoonlijk niet doen, want was is dan het nut van een groep? (Als ik me niet vergis noemt dit in de vakliteratuur totale disjunctie. Je behoort ofwel tot een groep ofwel heb je specifieke permissies. )
Toevoeging op 03/07/2012 16:11:44:
Wel toegegeven, dit staat -niet- zo beschreven in mijn startbericht. Dus het ERD klopt dan ook niet geheel meer.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
+-------------------------------+
| PermissionGroups |
+----+-------+------------+-----+
| id | name | removeUser | ... |
+----+-------+------------+-----+
| 1 | admin | 1 | ... |
| 2 | guest | 0 | ... |
+----+-------+------------+-----+
+---------------------+
| Users |
+----+-----+----------+
| id | ... | group_id |
+----+-----+----------+
| 1 | ... | 1 |
| 2 | ... | 2 |
| 3 | ... | 1 |
+----+-----+----------+
| PermissionGroups |
+----+-------+------------+-----+
| id | name | removeUser | ... |
+----+-------+------------+-----+
| 1 | admin | 1 | ... |
| 2 | guest | 0 | ... |
+----+-------+------------+-----+
+---------------------+
| Users |
+----+-----+----------+
| id | ... | group_id |
+----+-----+----------+
| 1 | ... | 1 |
| 2 | ... | 2 |
| 3 | ... | 1 |
+----+-----+----------+
Hierbij heeft User2 dus de rechten van een Guest (geen) en hebben User1 en User3 de rechten van een admin. Wat deze rechten precies zijn haal je dan uit de PermissionGroups tabel.
Gewijzigd op 03/07/2012 16:20:18 door Jeroen VD
Ik zeg nu maar wat, ik start een site op met wat mensen. Alleen, ik wil mezelf toegang geven tot een privé p* collectie (oké, absurd voorbeeld...), dan moet ik dus een extra groep aanmaken? Toch ook niet ideaal?
Jeroen, die groep zonder iets heet in mijn voorbeeldje 'guests'.
maar ja, extra duidelijk zo he?
Daarom ook dat ik dacht, een tabel met de gebruikers, een tabel met de groepen en een tabel met de permissies.
Wat altijd zeker is: een groep is verbonden aan een permissie record.
Een gebruiker daarentegen is OF met een groep verbonden OF met een permissie record. Nooit beide. (althans niet rechtstreeks) Volgens mij blijft dit dan toch de handigste manier?
Ook als je bijvoorbeeld nog verder gaat, je kent aan een gebruiker een groep toe, maar wilt bijvoorbeeld nog 1 extra permissie. Dan heeft een gebruiker dus zowel een groep record als een permissie record.
Dus elke gebruiker kan meerdere groepen hebben OF één permissie(record). En elke groep bevat één permissie(record).
Toevoeging op 04/07/2012 12:28:08:
Ik laat heel even het SQL gedeelte voor wat het is. Als iemand zich geroepen voelt om te reageren: graag!
Ik heb deze voormiddag al wat UML's zitten te tekenen en zou nu werkelijk willen starten met het programmeren. Alleen, na het herlezen van een post van Wouter zat ik even te denken. Ik kwam uit op SessionHandlerInterface. Die ga ik sowieso momenteel nog niet gebruiken. Ik wil mijn applicatie liefst werkend vanaf 5.3. (dit is bij mijn weten nu zo'n beetje de standaard) Uiteraard zou ik deze interface zelf kunnen implementeren.
Ik denk echter dat dat niet de bedoeling van Wouter was. Wat ikzelf nu van plan ben is in de 'Storage' klasse een aantal basis methoden zou gaan schrijven. Bijvoorbeeld om kunnen te schrijven naar een bestand en opslaan in de database. Ik zou dus SessionStorage laten extenden van Storage en e.v.t. de SessionHandlerInterface implementeren. Graag jullie meningen!
Ik denk bij het toekennen van rechten ook altijd OO.
- user_id (PK)
- user_name
- .....
tabel groups:
- group_id(PK)
- group_name
tabel user_in_group
- user_id(PK)
- group_id(PK)
tabel permissions
- perm_id
- perm_name
tabel object_permissions
- object_id(PK)
- user_or_group_id(PK)
- perm_id(PK)
tabel containers
- object_id
- object_name
Die laatste tabel is bedoeld om rechten te kunnen toekennen op bv de users en groups tabellen.
Dit lijkt misschien een beetje overkill, maar met dit systeem kun je dus over je hele website gericht rechten uitdelen, niet alleen puur in gebruikers gedeelte zelf.
Doe je het beide dan maak je je queries alleen maar nodeloos moeilijk en het levert je geen extra flexibiliteit op. Je kan namelijk altijd al een groep aanmaken voor 1 persoon. En in werkelijkheid kan ik me niet voorstellen dat je buiten een paar specifieke gevallen om (eigenaar, bepaalde VIP user) de rechten wil toekennen aan maar 1 persoon.
Pagina: « vorige 1 2 3 4 5 volgende »