Database ontwerp users en groepen

[L01]

In het programma dat ik aan het ontwerpen ben zitten een aantal deelnemers.
Deze deelnemers kunnen tot een groep behoren.

Een groep kan ook weer tot een groep behoren.

Mijn database ontwerp ziet er nu zo uit:




Dit werkt prima maar ik zit met het volgende probleem.

Als ik groep A heb met daarin groep B, dan is het mogelijk dat groep A ook weer in B zit En dat wil ik natuurlijk niet.

Een plaatje zegt meer:



Ik kan dit natuurlijk programma technisch oplossen maar is dit probleem database technisch op te lossen? Dat is natuurlijk een stuk makkelijker.

Ik heb gehoord dat hier een grafen theorie op toepasbaar moet zijn maar het is voor mij niet helemaal duidelijk hoe ik dit zou moeten doen.

[ Voor 3% gewijzigd door L01 op 13-01-2008 16:16 ]

[Orphix]

Welke database server gebruik je? Je zou een trigger kunnen aanmaken die bij een insert/update controleert of er circulaire referenties in de (nieuwe) hierarchie optreden.

[Verwijderd]

L01 schreef op zondag 13 januari 2008 @ 16:03:
In het programma dat ik aan het ontwerpen ben zitten een aantal deelnemers.
Deze deelnemers kunnen tot een groep behoren.
Een groep kan ook weer tot een groep behoren.

Stop hier.

1) Kunnen deelnemers tot meerdere groepen behoren?
2) Kunnen groepen tot meerdere andere groepen behoren?
3) Kunnen groepen tot hun eigen groep behoren?

[Verwijderd]

in MS access is dat in te stellen
gewoon in een query zetten (optie daarvoor in criteria maken)

[ Voor 51% gewijzigd door Verwijderd op 13-01-2008 16:31 ]

[Facer]

Ik werk samen met L01 aan het project. Hierbij de antwoorden op jullie vragen:

Orphix schreef op zondag 13 januari 2008 @ 16:15:
Welke database server gebruik je? Je zou een trigger kunnen aanmaken die bij een insert/update controleert of er circulaire referenties in de (nieuwe) hierarchie optreden.

- PostgreSQL 8.2.*
- Zou inderdaad een mogelijk zijn.

Verwijderd schreef op zondag 13 januari 2008 @ 16:19:
[...]

Stop hier.

1) Kunnen deelnemers tot meerdere groepen behoren?
2) Kunnen groepen tot meerdere andere groepen behoren?
3) Kunnen groepen tot hun eigen groep behoren?

1. Ja
2. Ja
3. Nee, dat willen we hiermee juist voorkomen.

Verwijderd schreef op zondag 13 januari 2008 @ 16:23:
in MS access is dat in te stellen
gewoon in een query zetten (optie daarvoor in criteria maken)

Heb je hiervan een voorbeeld? Of een suggestie welke kant we dan op moeten zoeken?

[ Voor 0% gewijzigd door Facer op 13-01-2008 16:34 . Reden: Typo ]

[Verwijderd]

optie like a>b ?

http://www.postgresql.org...e/functions-matching.html

[ Voor 79% gewijzigd door Verwijderd op 13-01-2008 16:41 ]

[Facer]

Verwijderd schreef op zondag 13 januari 2008 @ 16:38:
optie like a>b ?

Situatie:
Groep 1
Groep 2
Groep 3
Groep 4

Groep 1 zit in groep 2
Groep 2 zit in groep 3
Groep 3 zit in groep 4

Nu wil de gebruiker aan groep 4 de groep 1 toevoegen. Dan red je het volgens mij niet meer met een like query omdat je daar alleen 2 velden met elkaar vergelijkt.

[ Voor 7% gewijzigd door Facer op 13-01-2008 16:48 ]

[L01]

ah wat Facer zegt dus.

Het lijkt me dat iemand dit probleem al getackeld moet hebben, maar ik kan er niet veel over vinden.
Ik bedoel: dit is niet echt een zeldzame situatie ofzo..

[Niemand_Anders]

Ons profile systeem heeft helemaal geen probleem met een circulaire group reference. Wij voeren een query uit op de koppeltabel (Deelnemergroepdeelnemer). Beide colommen worden in een list (collectie/array) geplaatst en daarna ontdubbelt.

Via 'lazy loading' wordt de groep informatie pas opgehaalt als deze nodig is. Daarvoor hebben wij twee functies beschikbaar GroupDataRow LoadGroup(int groupID) en GroupDataTable LoadGroups(int[] groups). Beide functies doen eigenlijk hetzelfde. De loadGroups maakt alleen gebruik van een 'where in' query en plaatst de verschillende GroupDataRow instances in een collectie.

De enigste restrictie (check rule) welke wij hebben is dat een group niet naar zichzelf mag wijzen. Hoewel de software er geen problemen mee zal hebben, heeft het geen functionele toevoeging. Omdat ParentID en GroupID als clustered primary key zijn gedefineerd zorgt de database zelf ervoor dat groep A niet meerdere keren naar groep B kan wijzen.

Een ander methode welke ik een aantal jaren in PHP heb gezien is het gebruik van virtual groups. Groep A wordt dan niet gekoppeld aan groep B, maar er wordt een virtuele groep AB gemaakt welke referenties heeft naar groep A en B (en misschien eventueel zelf een groep C). De vrituele group wordt dan aan de user gekoppeld.

Een andere methode welke wij in ons (classic) ASP tijdperk aanhielden is dat groepen niet naar andere groepen wijzen, maar dat de gebruiker lid is van meerdere groepen. Eigenlijk het Windows groep principe.