TL;RD Las etiquetas reutilizables, los patrones de búsqueda complejos y las búsquedas de ascendencia en varios nodos descendientes (o un solo nodo cuya ruta aún no se ha recuperado) no se pueden lograr mediante un índice de ruta materializado.
Para aquellos interesados en los detalles sangrientos...
En primer lugar, su pregunta solo es relevante si no está reutilizando ninguna etiqueta en la descripción de su nodo. Si fuera así, el árbol l es realmente la única opción de los dos. Pero las implementaciones de rutas materializadas normalmente no necesitan esto, así que dejemos eso a un lado.
Una diferencia obvia estará en la flexibilidad en los tipos de búsquedas que le ofrece l-tree. Considere estos ejemplos (del ltree documentos vinculados en su pregunta):
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
La primera consulta obviamente se puede lograr con la ruta materializada. El último también se puede lograr, donde ajustaría la consulta como una búsqueda de hermanos. Sin embargo, el caso medio no se puede lograr directamente con una búsqueda de índice único. Tendría que dividir esto en dos consultas (todos los descendientes + todos los antepasados) o recurrir a un escaneo de tabla.
Y luego hay consultas realmente complejas como esta (también de los documentos):
Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain
Un índice de ruta materializado sería inútil aquí, y se requeriría un escaneo completo de la tabla para manejar esto. l-tree es la única opción si desea realizar esto como una consulta SARGable.
Pero para las operaciones jerárquicas estándar, encontrar cualquiera de:
- padre
- niños
- descendientes
- nodos raíz
- nodos hoja
la ruta materializada funcionará tan bien como l-tree. Contrariamente al artículo vinculado anteriormente , la búsqueda de todos los descendientes de un ancestro común es muy factible usando un árbol b. El formato de consulta WHERE path LIKE 'A.%' es SARGable siempre que su índice esté preparado correctamente (tuve que etiquetar explícitamente mi índice de ruta con varchar_pattern_ops para que esto funcione).
Lo que falta en esta lista es encontrar a todos los ancestros por un descendiente. El formato de consulta WHERE 'A.B.C.D' LIKE path || '.%' lamentablemente no va a utilizar el archivo index. Una solución alternativa que implementan algunas bibliotecas es analizar los nodos antecesores de la ruta y consultarlos directamente:WHERE id IN ('A', 'B', 'C') . Sin embargo, esto solo funcionará si se dirige a los ancestros de un nodo específico cuya ruta ya ha recuperado. l-tree va a ganar en este caso.
