database structuur

het is lastiger dan het lijkt! in ieder geval bedankt voor jullie hulp. ik zal even kijken hoe ik dat kan realiseren. Als jullie nog wat tips hebben, laat het me graag weten.

@Frank
Ja, ok, zo had ik het niet gelezen. Die queries kan je uiteraard zo 'flexibel' als je wilt bouwen. Probleem is alleen dat als het aantal lagen in je boom structuur variabel en dus van te voren onbekend is, je nog nergens bent. Want hoeveel self joins moet je die php class dan laten maken?

@George
Dit is inderdaad 1 van de wat lastigere zaken als het om data modeleren gaat. Een platte database is nu eenmaal niet gemaakt voor een echte boomstructuur. Elk model dat je dus bedenkt is van te voren eigenlijk niet perfect. Heel belangrijk is dan ook dat je de randvoorwaarden van je probleem helder hebt. In dit geval:
- hoeveel lagen mag je verwachten
- is dit aantal uit te breiden in de toekomst
- kan het zijn dat het echt variabel wordt of niet
- verwacht je veel mutaties op de data die je opslaat
- om hoeveel records zal het in totaal gaan
- wat voor soort views wil je kunnen bouwen

Afhankelijk van de antwoorden hierop kan je bepalen welke structuur het beste voor je is. De methode van Frank kan dan uiteindelijk nog steeds wel slimmer zijn om te gebruiken overigens. Het is niet bij voorbaat een slechte oplossing.

Ik zie een koppeltabel tussen afdeling en subafdeling, dus het lijkt er op dat een subafdeling bij meerdere afdelingen kan behoren, en dan zijn beide structuren niet mogelijk.

Volgens mij zie je dat verkeerd. De subafdelingen staan in een aparte tabel in het oorspronkelijke model van de TS (tabe: afdeling_subafdeling).
Never mind, staat er wel inderdaad.... Als dat inderdaad zo is, dan is het geen boomstructuur meer.

Veel organisaties hebben de hiërarchische boomstructuur inderdaad vervangen door een matrixstructuur. Daarbij kunnen de twee afdelingen X en Y bijvoorbeeld hetzelfde secretariaat Z delen.

Je zou dit kunnen modelleren door werknemers breder in te schalen: ze werken niet slechts op een afdeling, maar ze zijn bijvoorbeeld ook lid van een bepaald projectteam of hebben een bepaalde functieomschrijving.

Van het te strikt afgebakende "afdeling" maak je een ruimere container "organisatie-eenheid" of iets dergelijks. Aangezien je trainingen altijd geeft aan personen, relateer je die veel-op-veel aan zowel de organisatie-eenheden als de trainingen.

Zo kun je verschillende "dwarsdoorsneden" van elke organisatie maken. En dan ben je waar je wezen moet: je kunt nog steeds trainingen geven aan afdelingen, maar bijvoorbeeld ook aan alle leden van één projectgroep, aan alle werknemers met een bepaalde functiecategorie (alle secretaresses bijvoorbeeld, ongeacht hun afdeling), aan iedereen die op locatie X werkt, enzovoort, enzovoort.