database structuur
ik heb mijn database nu zo ingericht:
afdeling:
id
afd_naam
subafdeling:
id
subaf_naam
afdeling_subafdeling:
afdeling_id
subafdeling_id
training
id
training_naam
beschrijving
training_afd
afd_id
training_id
training_afd_subafd
afdeling_id
subafd_id
training_id
klopt deze database structuur?
moet ik de afdeling,subafdeling ophalen uit tabel afdeling_subafdeling en dan oplaan in tabel training_afd_subafd of moet ik het halen uit de tabellen afdeling en subafdeling en dan opslaan in training_afd_subafd? graag jullie hulp?
Gewijzigd op 25/05/2014 12:08:57 door George mendel
- Aar -:
Meerdere mensen hebben hier hulp nodig. Daarom wil ik je graag verzoeken om je titel aan te passen naar je vraag- of probleemstelling.
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
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
- 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
Frank Nietbelangrijk op 25/05/2014 12:21:22:
één training, meerdere (sub)afdelingen = one-to-many.
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
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
- 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
Code (php)
1
2
3
2
3
1. afdeling A
3. - afdeling X
2. afdeling B
3. - afdeling X
2. afdeling B
Code (php)
1
UPDATE afdelingen SET parent_id=2 WHERE id=3
Code (php)
1
2
3
2
3
1. afdeling A
2. afdeling B
3. - afdeling X
2. afdeling B
3. - afdeling X
Gewijzigd op 25/05/2014 13:12:14 door Frank Nietbelangrijk
Frank Nietbelangrijk op 25/05/2014 13:06:44:
Dat is geen probleem.
Code (php)
1
2
3
4
5
2
3
4
5
id parent_id naam
1 NULL afdeling A
2 1 subafdeling A1
3 1 subafdeling A2
4 3 subsubafdeling A21
1 NULL afdeling A
2 1 subafdeling A1
3 1 subafdeling A2
4 3 subsubafdeling A21
Code (php)
1
2
3
4
5
6
2
3
4
5
6
afdeling A
|
|-- subafdeling A1
|-- subafdeling A2
|
|-- subsubafdeling A21
|
|-- 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.
Gewijzigd op 25/05/2014 13:16:35 door Frank Nietbelangrijk
http://en.wikipedia.org/wiki/Nested_set_model
Geen eenvoudig model, maar wel veel robuster.
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?
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.
Gewijzigd op 25/05/2014 20:43:33 door Frank Nietbelangrijk
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.
Never mind, staat er wel inderdaad.... Als dat inderdaad zo is, dan is het geen boomstructuur meer.
Gewijzigd op 26/05/2014 09:34:08 door Erwin H
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.