Je kan toch met beide manieren hetzelfde? bekomen.
Ja en nee. Je ziet inderdaad vaak dat een db bouwer kiest voor aparte tabellen. En daar is in beginsel weinig mis mee. Zeker als je
van tevoren weet hoe diep de lagen gaan worden.
Belangrijker is het verschil in
gegevenstype tussen de tabellen. Een land is een andere entiteit als postcodereeks. Een postcodereeks heeft hele andere gegevens als een land, waar je wellicht een afkorting hebt en een landcode. Kortom: landen staan meestal in een aparte tabel, en straatnamen ook.
Bij een postcode database weet je meestal dat het eerste niveau een land is als je internationaal werkt, een provincie als je regionaal werkt, en een plaatsnaam als je lokaal werkt. Wat daaronder zit is dan meestal een straatnaam, en daaronder de postcodereeksen. Met dus steeds een verwijzingsveld naar het bovenliggende niveau. Dus in de tabel Plaatsen zet je een LandID, in Straatnaam zet je een PlaatsID en in Postcodes zet je een StraatID. Bij Postcodes houdt de scheiding op; dieper kun je niet gaan.
Kijken we naar de lokatietabel, dan is dat onderscheid een stuk kleiner. Bij het vastleggen van lokaties in dit voorbeeld gaat het eigenlijk alleen om het vastleggen van lokaties. Daarbij zit je in een soort van ui, die je steeds verder afpelt. Beter voorbeeld is wellicht het bekende Russische Matrushka popje. Daarbij haal je steeds kleinere identieke popjes uit de grotere pop. Zo is het ook met de lokaties. Je begint met de grootste lokatie, en de volgende lokatie is dus een kleiner gebied in de vorige lokatie. En de derde die je kiest is weer kleiner als de lokatie waar hij uit komt. In beginsel kun je die lokaties ook steeds verder specificeren; er hoeft geen eind aan te komen. Je kiest dus een land, daarna een provincie, daarna een plaats, daarna een lokatie, en desnoods kun je daar nog weer een aantal lokaties onder hangen. Er is geen fysieke belemmering, wat wél het geval is bij de constructie met vaste tabellen.
Ander voorbeeldje: als je een tabel hebt waarin een gebruiker een onderwerp moet kiezen, kun je dezelfde constructie gebruiken. Je kiest dan de eerste categorie, daarna de tweede, dan de derde optie, etc. Je kunt een oneindig aantal categorieën aan elkaar knopen, en dus steeds dieper in het poppetje duiken. Zou je daar losse tabellen voor gebruiken, dan zou je, als je 5 niveau's wilt hebben, daar 5 tabellen voor moeten maken. En dan zit je ook gelijk vast, want wil je een zesde categorielaag, dan heb je wéér een extra tabel nodig. Terwijl dat waarschijnlijk maar voor een paar categorieën nodig hoeft te zijn. Ook in dit voorbeeld staat in de tabel steeds hetzelfde type gegeven.
Laatste voorbeeld: een stamboomtabel. Hier doe je hetzelfde: je begint met de oudste persoon in te voeren, die op dat moment de stamvader/moeder is/zijn. De kinderen van de ouder(s) krijgen dan ParentID's naar die personen, en de kinderen daar weer van krijgen een verwijzing naar de kinderen van de eerste generatie. En zo verder. Vind je vervolgens de ouders van de 'stamoudsten', dan voer je die in zonder ParentID (want die heb je dan niet) en bij de eerste personen vul je dan achteraf alsnog het ParentID in. De stamboom heeft dan nieuwe stamoudsten gekregen. Dus: ook een oneindige boomconstructie.
Kortom: als je een flexibel systeem wilt hebben waarbij je niet beperkt wordt door het aantal lagen dat je kunt aanbrengen, kies je voor de constructie met één tabel met een ParentID. Elke nieuwe record hangt dan aan een ander record, behalve de eerste in de boom. Heb je een vaste diepte in je lagen, dan kun je overwegen om vaste tabellen te maken. Dit werkt zeker plezieriger als je érg veel data in je tabellen hebt. Een postcode tabel heeft heel wat records, en die wil je dus niet in dezelfde tabel hebben als de straatnamen en plaatsnamen, al zou dat technisch best wel kunnen.
. Wel heb ik het idee dat je een verkeerd begrip heb van 'parentID'. Dat is namelijk een verwijzing naar een ander record in dezelfde tabel. dus als je een tabel Locaties hebt met daarin als hoogste niveau Afdelingen, dan heeft zo'n record geen ParentID. Een locatie binnen een afdeling heeft dan wél een ParentID, want daarbij verwijs je naar het record van de afdeling. En dat is dus een ander ID nummer. 