TL;DR Genanvendelige etiketter, komplekse søgemønstre og herkomstsøgninger mod flere efterkommernoder (eller en enkelt knude, hvis sti endnu ikke er blevet hentet) kan ikke udføres ved hjælp af et materialiseret stiindeks.
For dem, der er interesseret i de blodige detaljer...
For det første er dit spørgsmål kun relevant, hvis du ikke genbruger nogen etiketter i din nodebeskrivelse. Hvis du var, er l-træet virkelig den eneste mulighed af de to. Men materialiserede stiimplementeringer har typisk ikke brug for dette, så lad os lægge det til side.
En åbenlys forskel vil være i fleksibiliteten i de typer søgninger, som l-tree giver dig. Overvej disse eksempler (fra ltree dokumenter, der er linket til i dit spørgsmål):
foo Match the exact label path foo
*.foo.* Match any label path containing the label foo
*.foo Match any label path whose last label is foo
Den første forespørgsel er naturligvis opnåelig med materialiseret sti. Det sidste er også muligt, hvor du vil justere forespørgslen som et søskendeopslag. Den mellemste sag er dog ikke direkte opnåelig med et enkelt indeksopslag. Du skal enten dele dette op i to forespørgsler (alle efterkommere + alle forfædre), eller ty til en tabelscanning.
Og så er der virkelig komplekse forespørgsler som denne (også fra dokumenterne):
Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain
Et materialiseret stiindeks ville være ubrugeligt her, og en fuld tabelscanning ville være påkrævet for at håndtere dette. l-tree er den eneste mulighed, hvis du ønsker at udføre dette som en SARG-forespørgsel.
Men for de hierarkiske standardoperationer, at finde en af:
- forælder
- børn
- efterkommere
- rodnoder
- bladknuder
materialiseret sti vil fungere lige så godt som l-træ. I modsætning til artiklen, der er linket ovenfor , er det meget muligt at søge efter alle efterkommere af en fælles forfader ved at bruge et b-træ. Forespørgselsformatet WHERE path LIKE 'A.%' kan SARG, forudsat at dit indeks er forberedt korrekt (jeg var nødt til eksplicit at mærke mit stiindeks med varchar_pattern_ops for at få det til at virke).
Det, der mangler på denne liste, er at finde alle forfædre for en efterkommer. Forespørgselsformatet WHERE 'A.B.C.D' LIKE path || '.%' kommer desværre ikke til at bruge indekset. En løsning, som nogle biblioteker implementerer, er at analysere forfaderknuderne fra stien og forespørge dem direkte:WHERE id IN ('A', 'B', 'C') . Dette vil dog kun fungere, hvis du målretter mod forfædre til en specifik node, hvis sti du allerede har hentet. l-tree kommer til at vinde på denne.