Idag hittade vi ltree i Postgres – och varför vi borde använt det för länge sen...
Idag snubblade vi över något i Postgres som jag nästan blir lite irriterad över att vi inte upptäckt tidigare: ltree. Ett inbyggt (nåja, extension) sätt att hantera hierarkier och trädstrukturer utan att behöva bygga massa egen logik.

Det här är sånt som man som utveclare har meckat med hundra gånger: kategoriträd, organisationsstrukturer, geografier, menyer, rättigheter… you name it. Och Postgres har alltså haft en lösning för detta sedan länge!

Så vad gör ltree egentligen?
Enkelt sagt: du sparar en path som representerar en nod i ett träd.
 
Typ:

Top.Europe.Sweden.VastraGotaland.Skovde

Det är inte text, det är en egen datatyp : ltree.

Det snygga är att Postgres fattar hierarkin och ger dig operators för att göra de queries man alltid behöver men som alltid blir lite meckiga:

Hitta allt under en nod
 path <@ 'Top.Europe.Sweden'

Hitta en nods ancestors
 path @> 'Top.Europe.Sweden.VastraGotaland.Skovde'

Djupet på en nod
 nlevel(path)

Hämta parent-noden
 subpath(path, 0, nlevel(path)-1)

Allt är optimerat med GIN/GiST-index, så det går fortare än ens egna hemmabyggen med adjacency lists eller materialiserade paths i textformat.

Varför det här är nice

Vi sitter ju ofta och bygger grejer där hierarkier finns överallt, men man försöker undvika att göra dem “riktiga” eftersom de blir jobbiga i SQL.

ltree tar bort det där. Det är varit perfekt i allt från:
kategoriträd
geografier (kommuner, regioner osv)
organisationsstrukturer
rättighetssystem
allt där det finns “under/över”-relationer

Och dessutom: det är Postgres. Ingen ny stack, ingen konstig tredjeparts-grej. Bara:

CREATE EXTENSION ltree;

Kommer jag använda det?
Ja.
 100% ja.

Jag önskar nästan att vi sett detta för många år sedan – det hade sparat ganska många timmar av “hur sjutton lagrar vi det här snyggt?”. Men bättre sent än aldrig.

Artiklar från EASCE

Idag hittade vi ltree i Postgres – och varför vi borde använt det för länge sen...