Maar dit moet toch kunnen met SQL?
Nee.
Ik heb een query nodig die alle boeken die opeenvolgend zijn weet te vinden.
Hoe weet je hoe vaak een loop moet worden doorlopen? De ene serie heeft 7 boeken (Potter) en de andere serie maar 3 (Lord of the Rings). En dan hebben we het nog niet over series als James Bond... Kortom: dat gaat nooit lukken met een lus in een query. Je moet dan namelijk voor elke tak een nieuwe kopie van de tabel toevoegen die je koppelt aan de vorige.
Hetzelfde principe heb je in een genealogie database, waar je een persoon toevoegt, en daar vervolgens de kinderen van toevoegt. Die hebben als vader dan het eerder toegevoegde record, en als moeder ook een ouder record. Dus in het veld V_ParentID vul je de vaderID in en in M_ParentID de moeder. Die personen hebben zelf uiteraard ook weer ouders, en als je die toevoegt aan de db kun je daarvoor ook een ParentID toevoegen. En zo voort. Wil je een familieoverzicht in een query, dan moet je van tevoren bepalen hoeveel generaties je wilt zien, want zoveel keer moet je de tabel toevoegen, en zoveel keer moet je ook de tabellen koppelen aan de respectievelijke ParentID's.
En nog een voorbeeldje: een tabel met categorieën en subcategorieën. Een onderwerp dat in dit forum nog wel eens voorbij komt. Daar worden vaak aparte tabellen voor gemaakt, maar dat vind ik niet echt handig, omdat je voor elke verdere onderverdeling weer een aparte tabel nodig hebt. Dan blijf je bezig met aanpassen. In dat geval gebruik ik één tabel, met een verwijzing naar een hogere categorie. Dus de tabel heeft een extra veld ParentID. Het hoogste niveau dat je in deze tabel vastlegt, de Hoofdcategorie dus, heeft, omdat het nu eenmaal het hoogste niveau is, geen waarden in de ParentID. En die kun je er dus makkelijk uitfilteren. Verder is het een kwestie van net zoveel klonen opnemen van de Categorie tabel als er niveau's zijn, zodat je alle subcategorieën correct kunt doorfilteren.
Een vergelijkbaar voorbeeldje heb je als je een bedrijfsprofiel gaat analyseren. Daar kun je een organisatiestructuur makkelijk maken door te beginnen bij de Directeur (hoogste niveau) en daaronder een laag managers die als ParentID gelinkt (verantwoording afdragen aan) de directeur, daar weer een groep mensen onder (teamleiders) die zijn gelinkt aan de manager, en daar weer personen onder die zijn gelinkt aan de teamleider.
Wat is er nu anders aan mijn voorbeeldje t.o.v. jouw vraag? Want je zou nu kunnen denken dat ik wel degelijk dezelfde oplossing gebruik als die jij zoekt. Het belangrijkste verschil: in mijn voorbeelden zijn de
entiteiten identiek. Een categorie is in essentie hetzelfde als een subcategorie, en als een subsubcategorie. Een familielid is per definitie een persoon, en dus als object identiek als ouder of kind. En een werknemer is als object altijd een werknemer. Een reeks boeken is echter een verzameling, en bestaat derhalve altijd uit meerdere niet van te voren bepaalde leden. En een boek is weer een altijd zelfstandige entiteit. Een boek is dus absoluut niet hetzelfde als een verzameling. En moet daarom anders worden behandeld.
Dus als je van tevoren
niet weet hoeveel boeken er gelinked zijn, dan heb je een groot probleem. Je kunt dan ervoor kiezen om dan maar een stevig aantal klonen van de tabel toe te voegen, en je suf te linken, zodat de kans groot is dat je
de meeste series wel hebt afgevangen, maar dat is niet echt een wetenschappelijke benadering.
Of je kiest voor mijn oplossing, die a) veel makkelijker is en b) geen beperkingen kent in het gebruik omdat die
altijd het gewenste resultaat oplevert.
Er is nog een (lastig) alternatief, en dat is dat je alles oplost met programmeren, dus met VBA. Daarin kun je wél een lus maken op basis van een bepaald gegeven. Maar dat moet je dus helemaal niet willen....
Vorig_boek geeft slechts aan op welk boek dit boek een vervolg is. (of een afleidend stuk zoals een vertaling)
