[PHP/MYSQL] Welk type hierarchie is het meest praktisch?

[Gigazone]

Zoals in eerdere topics aangegeven ben ik aan het proberen een EAV product database op te zetten in MySQL/MariaDB,

Inmiddels ben ik op het punt aanbeland waar ik naar categorieën moet gaan kijken.
Iedere feed van een leverancier geeft een categorie mee, sommige ook subcategorieën tot 4 a 5 levels. Iedere leverancier gebruikt ook nog eens eigen benaming. Dus het is een echt mengelmoesje.

Nu ben ik aan het kijken wat een goede manier zou zijn om categorieën in de database kan krijgen.
Zelf denk ik dat ik eerst een opschoning moet doen waarbij bijvoorbeeld "Friet" en "Patat" beide aan eenzelfde categorienaam of ID worden toegewezen. Of dat ik Patat hernoem naar Friet (of vice versa)

Daarnaast moeten er een hierarchische structuur worden aangebracht. Er is op internet vanalles te vinden, maar voornamelijk theoretisch en in het Engels waardoor sommige terminologie me even ontgaat.

Graag zou ik jullie mening willen aangaande wat het meest praktische is voor een productdatabase en wat ook nog behapbaar is voor een beginner.

Na research(o.a. link) kwam ik uit op

1) Adjacency Categories
2) Nested Categories (recursive CTE)
3) OQGRAPH

Wat zou het meest geschikt zijn? Naar ik begreep en zijn Adjecency Categories complex, voornamelijk bij een groter aantal categories. Dan zouden optie 2 en 3 overblijven.

[CH4OS]

Is dit aan de andere kant wel data dat je op een gestructureerde manier wilt opslaan?
Ik zou als ik jou zo lees, dit eerder opslaan in een Elastic Search / Lucene?

In de eerste regel uit het artikel dat je linkt wordt dat ook gezegd:

Most users at one time or another have dealt with hierarchical data in a SQL database and no doubt learned that the management of hierarchical data is not what a relational database is intended for.

[Gigazone]

CH4OS schreef op dinsdag 21 mei 2019 @ 12:15:
Is dit aan de andere kant wel data dat je op een gestructureerde manier wilt opslaan?
[...]

Dat is ook de reden dat ik advies vraag Ik denk dat volledig met Elastic Search / Lucene aan de slag gaan op het moment even buiten mijn competenties valt.

Ik heb gelezen in andere artikelen dat ze Elastic Search op de een of andere manier koppelen aan een MySQL database. En de Elastic Search database gebruiken om snelheidswinst te behalen mbt de zoekfunctie. Aangezien ik beginner ben wil ik mezelf ook niet overweldigen.


Wellicht zeg ik nu iets heel stoms, maar is het een idee om de informatie op te schonen en de data (raw) in een tabel in de MySQL database op te slaan. En op een later moment deze database te koppelen aan een elastic search database met frontend?

Op deze manier zou ik verder kunnen gaan met MySQL, er meer over leren, en als ik er klaar voor ben een frontend met elastic search kunnen opzetten waarbij ik dus profijt zou hebben van zowel de zoeksnelheid alsmede het hierarchische gedeelte.

[CurlyMo]

Een boomstructuur opslaan in je database is vrij recht toe recht aan:

code:

id | parent_id | value

Je waardes zijn dan:

code:

1 | NULL | 1
2 | NULL | 2
3 | 1 | 1.1
4 | 1 | 1.2
5 | 4 | 1.2.1

Selecteren uit een boom structuur kan inderdaad middels een recursive CTE. Probeer het resultaat uit die CTE zo beperkt mogelijk te houden, omdat verdere selecties op het resultaat van een CTE voor geen meter presteren.

Ik kan overigens hier je link niet openen gezien firewall, maar bovenstaand is wat ik normaliter doe.

Of een boomstructuur de juiste oplossing is voor je doel is een tweede. Daarvoor zullen we meer inzicht moeten hebben in je data en doel.

[Gigazone]

CurlyMo schreef op dinsdag 21 mei 2019 @ 12:37:

Of een boomstructuur de juiste oplossing is voor je doel is een tweede. Daarvoor zullen we meer inzicht moeten hebben in je data en doel.

Als ik dus een categorie structuur wil hebben net als bijv de PW of Bol.com kan ik dus beter gebruik maken van een "recht toe recht aan" oplossing in plaats van me allerlei andere dingen op de hals te halen.

[CurlyMo]

Ja. Die nested structuur en graph structuren wil je het liefst kunnen bevragen vanuit de daarvoor geschikte database systemen. MySQL is dat (zover ik weet) niet. In PostgreSQL zou je nog terug kunnen vallen op PostGIS. De simpelste oplossing geeft je ook de minste synchronisatieproblemen wanneer je je structuur opeens toch wil omgooien.

Het verplaatsen van een tak naar een andere tak (op welk niveau dan ook) is simpel het aanpassen van de parent_id. Alle onderliggende takken veranderen door je structuur automatisch mee.

Daarnaast werd als nadeel van die simpele oplossing het gebrek aan recursive CTE genoemd in MySQL, maar dat wordt tegenwoordig ook ondersteund.

[Kalentum]

Ik raad Nested Sets aan. De naïeve implementatie van een hiërarchische structuur (met alleen parent_id) heeft veel database queries nodig om 1x de hierarchy op te halen. Ik zou dat alleen maar overwegen bij 2 levels en weinig categorien

Er zijn voor de meeste talen wel kant en klare implementaties te vinden dus je hoeft dat allemaal niet zelf te implementeren.

Ik ga ervan uit dat MySQL niet zoals als dit heeft https://www.postgresql.org/docs/11/ltree.html ?

[kwaakvaak_v2]

CurlyMo schreef op dinsdag 21 mei 2019 @ 12:54:
Ja. Die nested structuur en graph structuren wil je het liefst kunnen bevragen vanuit de daarvoor geschikte database systemen. MySQL is dat (zover ik weet) niet. In PostgreSQL zou je nog terug kunnen vallen op PostGIS. De simpelste oplossing geeft je ook de minste synchronisatieproblemen wanneer je je structuur opeens toch wil omgooien.

HUH postGIS? Dat is volgens mij bescheiden mening niet één maar misschien wel drie bruggen te ver in deze

MariaDB heeft Dynamic colums maar of je die nu wilt gebruiken is maar de vraag. Het is voor zover ik weet een eigen toevoeging van MariaDB op MySQL.

Als de OP niet zoals in je eerdere antwoord gebruik wil/kan maken van een boomstructuur is het misschien wel te doen om de JSON Datatypes die zijn in MariaDB en MySQL te gebruiken. Plus daar zijn in PHP wel abstractie's voor te vinden.

[CurlyMo]

rutgerw schreef op dinsdag 21 mei 2019 @ 13:09:
Ik raad Nested Sets aan. De naïeve implementatie van een hiërarchische structuur (met alleen parent_id) heeft veel database queries nodig om 1x de hierarchy op te halen. Ik zou dat alleen maar overwegen bij 2 levels en weinig categorien

Nee, hoor. Lees je maar eens in in de recursive CTE

kwaakvaak_v2 schreef op dinsdag 21 mei 2019 @ 13:09:
[...]
HUH postGIS? Dat is volgens mij bescheiden mening niet één maar misschien wel drie bruggen te ver in deze

Daarvoor ken ik nested sets te slecht. Maar als ik lees dat je moet bepalen of AB binnen XY ligt, dan denk ik al snel aan geometrische selecties. Misschien was ik iets te voorbarig

MariaDB heeft Dynamic colums maar of je die nu wilt gebruiken is maar de vraag. Het is voor zover ik weet een eigen toevoeging van MariaDB op MySQL.

Dat wordt heel lelijk

Als de OP niet zoals in je eerdere antwoord gebruik wil/kan maken van een boomstructuur is het misschien wel te doen om de JSON Datatypes die zijn in MariaDB en MySQL te gebruiken. Plus daar zijn in PHP wel abstractie's voor te vinden.

Dat is toch totaal niet lekker in je selecties.

[Kalentum]

CurlyMo schreef op dinsdag 21 mei 2019 @ 13:28:
[...]

Nee, hoor. Lees je maar eens in in de recursive CTE

Achter de schermen moet MySQL dan nog steeds 'for each recursion' een query (index of table scan) doen.

[CurlyMo]

rutgerw schreef op dinsdag 21 mei 2019 @ 13:34:
[...]


Achter de schermen moet MySQL dan nog steeds 'for each recursion' een query (index of table scan) doen.

Maakt dat uit, als het maar presteert? De grap is ook dat die Wikipedia pagina waarnaar je linkt het zelf zegt:

Queries using nested sets can be expected to be faster than queries using a stored procedure to traverse an adjacency list, and so are the faster option for databases which lack native recursive query constructs, such as MySQL.[4] However, recursive SQL queries can be expected to perform comparably for 'find immediate descendants' queries, and much faster for other depth search queries, and so are the faster option for databases which provide them, such as PostgreSQL,[5] Oracle,[6] and Microsoft SQL Server.[7]

Punt 1 vervalt want MySQL ondersteund nu ook recursive CTE's. En aangezien Punt 1 vervalt, wordt punt 2 een aanvullend voordeel

En we weten niet hoe het functionele doel gemak zich verhoudt tot prestatie. Als prestaties nog lang geen probleem vormen is het sowieso goed om voor het traditionele model te kiezen, want dat is veel makkelijker neer te zetten.

[ Voor 10% gewijzigd door CurlyMo op 21-05-2019 13:42 ]

[Kalentum]

Ik denk(!) dat het bij kleine datasets (bv 5 hoofdcategorieen en 1-3 sub categorien) uiteindelijk niet zoveel uitmaakt maar bij wat grotere structuren wel, met meer niveaus. Misschien aanleiding om eens een performance test te doen

[Matis]

rutgerw schreef op dinsdag 21 mei 2019 @ 13:54:
Ik denk(!) dat het bij kleine datasets (bv 5 hoofdcategorieen en 1-3 sub categorien) uiteindelijk niet zoveel uitmaakt maar bij wat grotere structuren wel, met meer niveaus. Misschien aanleiding om eens een performance test te doen

Mijn eerste ingeving waren ook nested sets. Ik zal eens een test opzetten en de code + resultaten hier delen.

[CurlyMo]

Matis schreef op dinsdag 21 mei 2019 @ 14:05:
[...]

Mijn eerste ingeving waren ook nested sets. Ik zal eens een test opzetten en de code + resultaten hier delen.

Ik ben erg benieuwd naar de resultaten, maar laten we eerst afwachten of prestatie wel zo belangrijk is voor @Gigazone .

[kwaakvaak_v2]

CurlyMo schreef op dinsdag 21 mei 2019 @ 13:28:
[...]

Dat is toch totaal niet lekker in je selecties.

Valt nog wel mee, er zijn wat functies om een query in de json te doen

Persoonlijk zou ik er voor kiezen als het doorzoekbaar en performant moet zijn om naar Solr of Elastic te indexeren. Bulkdata opslaan in SQL in een 'plat' dataformaat en dan een indexer in een systeem wat daar gewoon heel goed in is.

Bijkomend voordeel is dan ook als je iets als faceted search moet gaan doen je geen complexe o⁽ⁿ⁾ queries nodig hebt. Hoeft ook niet heel complex qua code te zijn als je Solarium in combo met Solr gebruikt.

[Matis]

CurlyMo schreef op dinsdag 21 mei 2019 @ 14:28:
Ik ben erg benieuwd naar de resultaten, maar laten we eerst afwachten of prestatie wel zo belangrijk is voor @Gigazone .

Persoonlijk vraag ik me af of beide voorstellen wel goed zijn. Hoe om te gaan met producten die in (direct of indirect) in te delen vallen in meerdere categorieën.

Om in zijn voorbeeld te blijven: Friet (of Patat, maar dat doet voor dit voorbeeld niets af) kan zowel onder de categorie Aardappelgerechten als Fast-Food vallen.

[ Voor 26% gewijzigd door Matis op 21-05-2019 15:00 ]

[CurlyMo]

Matis schreef op dinsdag 21 mei 2019 @ 15:00:
[...]
Persoonlijk vraag ik me af of beide voorstellen wel goed zijn. Hoe om te gaan met producten die in (direct of indirect) in te delen vallen in meerdere categorieën.

Opnieuw zullen we eerst meer moeten weten van de functionele specificaties van @Gigazone.

Om in zijn voorbeeld te blijven: Friet (of Patat, maar dat doet voor dit voorbeeld niets af) kan zowel onder de categorie Aardappelgerechten als Fast-Food vallen.

Je tree extern beleggen middels een koppeltabel.

[The Eagle]

DIt gaat nodeloos ingewikkeld worden zo. Kijk naar een NoSQL database, en niet naar iets relationeels als MySQL.
Stel je hebt twee artikelen: een laptop en een potplant. Ieder artikel heeft productkenmerken (schermdiagonaal, processor) maar die komen niet overeen. Binnen een bepaalde productfamilie kom je nog wel een eind, maar ook daar weet je niet welke data je vooraf van je leverancier gaat krijgen. En een potplan heeft hele andere eigenschappen dan een laptop. Toch wil je die in een zelfde soort tabel kwijt.

Trust me: zo doen jongens als Bol en Amazon het ook. je wilt dit niet in SQL oplossen.

[CurlyMo]

The Eagle schreef op dinsdag 21 mei 2019 @ 15:23:
DIt gaat nodeloos ingewikkeld worden zo.

Volgens mij is de scope van de vraag het maken van een productcategorieën boom. Volgens mij kan dat prima in SQL. De producten zelf met hun kenmerken is een stuk complexer.

[The Eagle]

Wellicht, maar
1) er zijn dus meer topic van allerlei dingen waar TS tegenaan loopt
2) zo blijf je aan de gang

Les: bezint eer ge begint. Eerst kijken wat je doel is, dan de tools bedenken en dan pas implementeren

[CurlyMo]

The Eagle schreef op dinsdag 21 mei 2019 @ 19:14:
Wellicht, maar
1) er zijn dus meer topic van allerlei dingen waar TS tegenaan loopt
2) zo blijf je aan de gang

Les: bezint eer ge begint. Eerst kijken wat je doel is, dan de tools bedenken en dan pas implementeren

Helemaal waar, maar dat maakt de individuele concepten niet minder leerzaam

[Gomez12]

The Eagle schreef op dinsdag 21 mei 2019 @ 15:23:
Stel je hebt twee artikelen: een laptop en een potplant. Ieder artikel heeft productkenmerken (schermdiagonaal, processor) maar die komen niet overeen. Binnen een bepaalde productfamilie kom je nog wel een eind, maar ook daar weet je niet welke data je vooraf van je leverancier gaat krijgen. En een potplan heeft hele andere eigenschappen dan een laptop. Toch wil je die in een zelfde soort tabel kwijt.

Trust me: zo doen jongens als Bol en Amazon het ook. je wilt dit niet in SQL oplossen.

Trust me, zo doen jongens als Bol en Amazon het niet.

The Eagle schreef op dinsdag 21 mei 2019 @ 19:14:
Les: bezint eer ge begint. Eerst kijken wat je doel is, dan de tools bedenken en dan pas implementeren

Correct, en als je gaat kijken naar het doel dan kom je juist op een RDBMS uit en juist niet op een NO-SQL.

Want het doel is een productvergelijker, oftewel je kan alle data van de leverancier aan de kant schuiven / ommappen naar je eigen kenmerken waarna je op je eigen kenmerken kan vergelijken.
Hetzelfde geldt voor je categorieën, je kan alle leveranciers categorieën opzij schuiven / mappen naar je eigen categorieën want je gebruikt geen leveranciers categorieën maar alleen je eigen.

Een No-SQL is leuk om de leveranciers data om te mappen naar je eigen data, maar je eigen data kent gewoon een vaste kenmerkenset en een vaste categorieën set en past bijna altijd gewoon in een RDBMS.

Een partij als een Bol en Amazon die gebruiken NO-SQL als frontend dbases gevoed door RDBMS'en. En al het beheer vind plaats in de RDBMS'en... Puur omdat No-Sql dbases standaard weinig middelen kennen om structuur te bewaken en bewaren.

@TS : Wat je kan doen is gewoon vanaf scratch een eigen hiërarchische categorie opzetten, daarnaast sla je over het algemeen die categorisering van de leverancier los op en map je daarna de categorisering van de leverancier naar je eigen categorieën.
Zodat elk artikel aan 2 categorieën hangt, 1 : die van de leverancier, 2 : die van jou.
Hier zit alleen 1 groot nadeel aan, wat doe je met dubbel gecategoriseerde artikelen, ga jij die ook 2x bij jezelf categoriseren?
Bijv jouw voorbeeld patat/friet. Dat wordt verkocht in supermarkten en in frietzaken en daar zijn het 2 verschillende producten (de een is wel bereid en de ander niet), alleen als je een groothandel hebt die verkoopt het aan beide en daar is het product hetzelfde. Oftewel als jij in je hiërarchische categorie een tak supermarkt en een tak frietzaken gaat maken (bekeken vanuit de consument) dan kan de groothandel nergens zijn product kwijt.

Wat nog wel eens daarom gebruikt wordt is dat jij juist geen hiërarchische boom opzet, maar puur een 1 of 2-laags producten indeling met daaraan gekoppeld specifieke kenmerken.
Waarna je als stap 2 1 of meerdere hiërarchische bomen gaat opzetten die gebouwd zijn op je producten indelingen met daaraan gekoppeld specifieke kenmerken.
Als je nu een productgroep patat / friet aanmaakt met daarbij 2 verplichte kenmerk : inhoud van de zak / gefrituurd ja/nee.
Dan kan je dus een hiërarchie opzetten waarbij je zegt dat de >3 liter ongefrituurde zakken naar categorie 1 gaan (groothandels die aan frietzaken leveren) alle <5 liter ongefrituurde zakken gaan naar categorie 2 (groothandels die aan supermarkten leveren / supermarkten die aan consumenten leveren ) en alle gefrituurde zakken gaan naar categorie 3 (de frietzaken)
En dan heb je dus dat alles tussen de 3 en de 5 liter automatisch in 2 categorieën valt zonder dat de leverancier (of jij) iets 2x hoeft te categoriseren

[Gigazone]

The Eagle schreef op dinsdag 21 mei 2019 @ 19:14:
Wellicht, maar
1) er zijn dus meer topic van allerlei dingen waar TS tegenaan loopt
2) zo blijf je aan de gang

Les: bezint eer ge begint. Eerst kijken wat je doel is, dan de tools bedenken en dan pas implementeren

Sorry maar dat is een beetje kort door de bocht. Omdat ik op één punt wil beginnen en het stap voor stap PHP, MySQL en wellicht andere aspecten wil leren dmv het opzetten van een functioneel iets, is het ineens iets wat ik vantevoren volledig had moeten ontwerpen en bedenken? En mag meerdere vragen stellen ook al niet meer? Ik kom hier om iets te leren, ik vraag ook niemand om iets voor me te ontwikkelen, ik vraag alleen wat meningen en pointers. Each Journey Begins With a Single Step.

Ik snap best dat je in een professionele omgeving eerst alles in kaart gaat brengen, doelen stellen en dan pas begint. Daarnaast werken bij BOL en Amazon 100'en of misschien wel 1000'en programmeurs met jaren ervaring, dat valt niet te vergelijken met iemand die net om de hoek komt kijken en in zijn vrije tijd iets nieuws probeert te leren.

CurlyMo schreef op dinsdag 21 mei 2019 @ 14:28:
[...]

Ik ben erg benieuwd naar de resultaten, maar laten we eerst afwachten of prestatie wel zo belangrijk is voor @Gigazone .

Het is een hobbyproject voornamelijk ter lering en vermaak. Prestatie is van ondergeschikt belang op het moment. Ik heb op zich ook niets tegen een boomstructuur.

Gomez12 schreef op dinsdag 21 mei 2019 @ 22:05:
[...]
Een partij als een Bol en Amazon die gebruiken NO-SQL als frontend dbases gevoed door RDBMS'en. En al het beheer vind plaats in de RDBMS'en... Puur omdat No-Sql dbases standaard weinig middelen kennen om structuur te bewaken en bewaren.

Bol.com 4 jaar uit voor het implementeren van Elastic Search als primaire data opslag ([url]link[[/url])
Maar ik zat in dezelfde lijn als u te denken maar voornamelijk omdat er voor NoSQL is er (te) weinig informatie te vinden is online. Ik vrees dat ik mezelf dan te veel op de hals zou halen. Maar als ik eerst RDBMS kan leren als backend kan het later nog aan een Elastic Search frontend geknoopt worden.

Gomez12 schreef op dinsdag 21 mei 2019 @ 22:05:
@TS : Wat je kan doen is gewoon vanaf scratch een eigen hiërarchische categorie opzetten, daarnaast sla je over het algemeen die categorisering van de leverancier los op en map je daarna de categorisering van de leverancier naar je eigen categorieën.
Zodat elk artikel aan 2 categorieën hangt, 1 : die van de leverancier, 2 : die van jou.
Hier zit alleen 1 groot nadeel aan, wat doe je met dubbel gecategoriseerde artikelen, ga jij die ook 2x bij jezelf categoriseren?

Probleem is dat er meerdere leveranciers zijn, met ieder eigen benamingen voor de categorie, en bijvoorbeeld bol 4 of 5 levels gebruikt, maar coolblue maar 2 ofzo. Dus ik moet op de een of andere manier het in een uniforme vorm gieten zodat ik het kan verwerken.

Gomez12 schreef op dinsdag 21 mei 2019 @ 22:05:
Wat nog wel eens daarom gebruikt wordt is dat jij juist geen hiërarchische boom opzet, maar puur een 1 of 2-laags producten indeling met daaraan gekoppeld specifieke kenmerken.

Moet ik dan denken aan bijvoorbeeld 1 categorie (Eten) met een subcategorie (Aardappel producten) met daarnaast taxonomies: bevroren, 1kg, geschild, gebakken, etc? Of denk ik dan in de verkeerde richting?

[CurlyMo]

Gigazone schreef op dinsdag 21 mei 2019 @ 22:44:
[...]
Het is een hobbyproject voornamelijk ter lering en vermaak. Prestatie is van ondergeschikt belang op het moment. Ik heb op zich ook niets tegen een boomstructuur.

Dan gewoon lekker mijn voorgestelde boom structuur gebruiken. Leer je gelijk weer wat over recursie.

Bol.com 4 jaar uit voor het implementeren van Elastic Search als primaire data opslag ([url]link[[/url])
Maar ik zat in dezelfde lijn als u te denken maar voornamelijk omdat er voor NoSQL is er (te) weinig informatie te vinden is online. Ik vrees dat ik mezelf dan te veel op de hals zou halen. Maar als ik eerst RDBMS kan leren als backend kan het later nog aan een Elastic Search frontend geknoopt worden.

Begin eerst maar eens met goed begrijpen wat een RDBMS wél goed kan om je daarna te verdiepen waarom er ook andere database systemen zijn zoals bijv. NoSQL, Graph, Timeserie databases.

Probleem is dat er meerdere leveranciers zijn, met ieder eigen benamingen voor de categorie, en bijvoorbeeld bol 4 of 5 levels gebruikt, maar coolblue maar 2 ofzo. Dus ik moet op de een of andere manier het in een uniforme vorm gieten zodat ik het kan verwerken.

Wat eerder al is voorgesteld je eigen indeling verzinnen en de aangevoerde data daarnaartoe vertalen.

Moet ik dan denken aan bijvoorbeeld 1 categorie (Eten) met een subcategorie (Aardappel producten) met daarnaast taxonomies: bevroren, 1kg, geschild, gebakken, etc? Of denk ik dan in de verkeerde richting?

Zoals je zelf al zegt, je bent aan het leren vanuit Hobby. Begin daar gewoon eens mee en loop dan lekker vast

Waar ik bijv. nu al aan denk. Is drinken ook eten ?

[ACM]

Ik zou het simpel beginnen en als dat niet blijkt te voldoen, dan pas moeilijk gaan doen.

Hou er verder rekening mee dat veel van die adviezen mbt SQL-opslag om een of andere reden aannemen dat je alles in SQL wilt doen. Dat is in de echte wereld natuurlijk niet per se nodig. Zeker met een beperkt aantal categorieen kan het prima mogelijk zijn om domweg alles op te halen en de 'moeilijke' operaties in je applicatielaag te doen. En vaak is domweg voor iedere laag een losse query ook goed genoeg.

De simpelste is uiteraard de adjacancy variant. Op dit moment gebruiken we dat ook bij Tweakers, hoewel de meeste retrieval-queries uiteindelijk helemaal voor-geserialized uit onze java-backend komen. Dus ik durf niet te zeggen in hoeverre die 240 nog steeds als 'beperkt' kan worden beschouwd

Nested set of e.o.a. boom-notatie zorgt dat sommige vormen van retrieval veel sneller gaan, maar ze voegen ook complexiteit toe als je wijzigingen wilt aanbrengen in de hierarchie. Dus zijn die retrieval-vormen echt nodig voor je? En dan dus de moeite van complexere wijzigingen waard?

Overigens zou ik sowieso altijd de adjacancy-waardes opslaan. Zeker bij de nested set zijn er maar een beperkt aantal queries efficient, kijk in je eigen voorbeeldcode maar naar de "Immediate Subordinates of a Node"-query...

Dus ik zou niet puristisch alleen de 'lft' en 'rgt' opslaan, maar ook het parentid; dan kan je bovendien ook netjes foreign key relaties leggen tussen parents en childs. Anderen slaan slaan ook de 'depth' expliciet op, maar dat moet je uiteraard alleen doen als dat iets is wat je nodig hebt (als je bijv 2 niveaus diep onder een parent wilt opvragen kan dat handig zijn).

Overigens kan je de adjacancy variant later vrij eenvoudig alsnog omzetten in een nested set, boomnotatie of een andere vorm. Je hoeft er tenslotte alleen maar extra kolommen aan toe te voegen en die op de juiste wijze te vullen.

[ Voor 3% gewijzigd door ACM op 22-05-2019 08:53 ]

[CurlyMo]

ACM schreef op woensdag 22 mei 2019 @ 08:52:
Hou er verder rekening mee dat veel van die adviezen mbt SQL-opslag om een of andere reden aannemen dat je alles in SQL wilt doen. Dat is in de echte wereld natuurlijk niet per se nodig. Zeker met een beperkt aantal categorieen kan het prima mogelijk zijn om domweg alles op te halen en de 'moeilijke' operaties in je applicatielaag te doen. En vaak is domweg voor iedere laag een losse query ook goed genoeg.

De simpelste is uiteraard de adjacancy variant.

In mijn pre-postgres, pre-mysql-recursive-cte en pre-stored-procedure-kennis tijd handelde ik alles wat recursief moest zijn ook gewoon af in mijn applicatie laag. Nu hebben we de luxe alleen wel van de recursive CTE dus is het wel zo netjes om het in een keer in je database te doen. Idealiter pik je gelijk de handig en onhandigheid van een CTE op.

[ACM]

CurlyMo schreef op woensdag 22 mei 2019 @ 09:00:
[...]

In mijn pre-postgres, pre-mysql-recursive-cte en pre-stored-procedure-kennis tijd handelde ik alles wat recursief moest zijn ook gewoon af in mijn applicatie laag. Nu hebben we de luxe alleen wel van de recursive CTE dus is het wel zo netjes om het in een keer in je database te doen. Idealiter pik je gelijk de handig en onhandigheid van een CTE op.

Oh, zeker eens. Als je een voldoende moderne MySQL(-variant) kan gebruiken, dan heeft de CTE ook mijn voorkeur

Maar dan dus alsnog met de simpele adjacancy list opslag

[Gigazone]

CurlyMo schreef op woensdag 22 mei 2019 @ 08:01:
[...]
Waar ik bijv. nu al aan denk. Is drinken ook eten ?

Een glas bier is 2 bruine boterhammen met kaas is me altijd verteld, dus dan is het inderdaad eten.

ACM schreef op woensdag 22 mei 2019 @ 08:52:
Ik zou het simpel beginnen en als dat niet blijkt te voldoen, dan pas moeilijk gaan doen.

<knip>
Overigens kan je de adjacancy variant later vrij eenvoudig alsnog omzetten in een nested set, boomnotatie of een andere vorm. Je hoeft er tenslotte alleen maar extra kolommen aan toe te voegen en die op de juiste wijze te vullen.

Bedankt voor je uitgebreide antwoord. Ik ga adjacancy variant aan de slag, en wellicht dat ik dan de boomnotatie direct meeneem als ik toch kolommen ga vullen. Ik begrijp dat ik met deze methode nog altijd alle kanten op kan. dus dat lijkt me het meest geschikt voor me op dit moment.