database structuur

één training, meerdere (sub)afdelingen = one-to-many.

tabel afdelingen:
- id		primary index
- training_id	index naar de tabel trainingen
- parent_id	index naar dezelfde tabel om aan te geven onder welke categorie deze subcategorie valt of anders NULL
- naam		naam van de afdeling

tabel training
- id		primary index
- description	omschrijving van de training

is er geen andere manier dan een parent id te gebruiken? want afdelingen kunnen in de tabel afdeling nog toegevoegd gewijzigd worden!

Frank Nietbelangrijk op 25/05/2014 12:21:22

één training, meerdere (sub)afdelingen = one-to-many.

tabel afdelingen:
- id		primary index
- training_id	index naar de tabel trainingen
- parent_id	index naar dezelfde tabel om aan te geven onder welke categorie deze subcategorie valt of anders NULL
- naam		naam van de afdeling

tabel training
- id		primary index
- description	omschrijving van de training

Dat is geen probleem.

1. afdeling A
3.   - afdeling X
2. afdeling B

UPDATE afdelingen SET parent_id=2 WHERE id=3

1. afdeling A
2. afdeling B
3.   - afdeling X

en hoe zit het dan met de subafdelingen? want 1 afdeling heeft weer meerdere subafdelingen?

Frank Nietbelangrijk op 25/05/2014 13:06:44

Dat is geen probleem.

ok:

id parent_id naam
1  NULL      afdeling A
2  1         subafdeling A1
3  1         subafdeling A2
4  3         subsubafdeling A21

afdeling A
   |
   |-- subafdeling A1
   |-- subafdeling A2
          |
          |-- subsubafdeling A21

Toevoeging op 25/05/2014 13:20:10:

Het is een zogenaamde boomstructuur. elke tak zit weer aan een andere tak of aan de boomstam die je ook als de hoofdtak zou kunnen zien.

Ai, niet op die manier een boom gaan opslaan in je database. Dat gaat hardstikke fout op het moment dat je boom meer lagen krijgt dan je vooraf had verwacht. Als je namelijk alle parents wil hebben voor afdeling x, dan moet je in je query voor elke laag een extra self join maken. Als dat aantal dus variabel is dan is het niet meer te doen. Gebruik daarvoor in plaats een nested set.

http://en.wikipedia.org/wiki/Nested_set_model

Geen eenvoudig model, maar wel veel robuster.

Inderdaad redelijk ingewikkeld. Is er geen standaard PHP class die het zware werk van je overneemt?
Ik lees tevens dat een update query al gauw een zware opdracht is in dit model. Is het dan niet juist handiger om bij kleinere bomen een simpel model als de mijne aan te houden?

Een php oplossing kan hierin geen oplossing zijn, omdat je dan eerst alle data uit je database moet halen, om vervolgens in php te gaan filteren etc. Als het in de database te zwaar wordt, dan zeker in php ook.

Inserts, updates en deletes kunnen inderdaad redelijk zwaar worden in dit model en dus niet aan te raden voor data waar erg veel mutaties op plaats vinden. Data die echter redelijk statisch is (en bij bedrijfsafdelingen stel ik mij voor dat dat zo is), is het vele malen beter dan het model dat jij gaf. Alleen als je van te voren 100% zeker weet dat er nooit meer lagen in het model komen kan je ervoor kiezen dat model te gebruiken. Dan kan je namelijk van te voren alle queries baseren op het aantal lagen dat je hebt. Zelf kies ik er echter nooit meer voor, simpelweg omdat het nested set model in veel meer opzichten veel bruikbaarder is.

Ik snap dat er geen PHP oplossing voor is maar een class die de juiste queries voor je maakt zou toch wel moeten kunnen?