Organisatieschema's modelleren in PostgreSQL: adjacency-lijsten vs closure

Wat een organigram moet ondersteunen

Een organigram is een kaart van wie aan wie rapporteert, en hoe teams optellen tot afdelingen. Wanneer je een organigram in PostgreSQL modelleert, sla je niet alleen een manager_id op bij elke persoon. Je ondersteunt echt werk: org-browsen, rapportage en toegangsregels.

De meeste gebruikers verwachten drie dingen die direct aanvoelen: het verkennen van de organisatie, mensen vinden en resultaten filteren naar "mijn gebied". Ze verwachten ook dat updates veilig zijn. Als een manager verandert, moet het schema overal bijwerken zonder rapporten of permissies te breken.

In de praktijk moet een goed model een paar terugkerende vragen kunnen beantwoorden:

• Wat is de keten van bevelvoering van deze persoon (tot aan de top)?
• Wie valt onder deze manager (directe rapporten en de volledige subtree)?
• Hoe groeperen mensen zich in teams en afdelingen voor dashboards?
• Hoe verlopen reorganisaties zonder glitches?
• Wie mag wat zien, op basis van de org-structuur?

Het wordt lastiger dan een simpele boom omdat organisaties vaak veranderen. Teams verplaatsen tussen afdelingen, managers wisselen groepen en sommige weergaven zijn niet puur "mensen rapporteren aan mensen". Bijvoorbeeld: een persoon hoort bij een team, en teams horen bij afdelingen. Permissies voegen een extra laag toe: de vorm van de organisatie wordt deel van je beveiligingsmodel, niet alleen een diagram.

Enkele termen helpen ontwerpen helder te houden:

• Een node is één item in de hiërarchie (een persoon, een team of een afdeling).
• Een ouder (parent) is de node direct erboven (een manager, of een afdeling die een team bezit).
• Een ancestor is elke node erboven op willekeurige afstand (de manager van je manager).
• Een descendant is elke node eronder op willekeurige afstand (iedereen onder jou).

Voorbeeld: als Sales onder een nieuwe VP gaat, moeten twee dingen onmiddellijk waar blijven. Dashboards filteren nog steeds "heel Sales", en de permissies van de nieuwe VP dekken Sales automatisch.

Beslissingen om te maken voordat je een tabelontwerp kiest

Voordat je een schema kiest, wees duidelijk over wat je app elke dag moet beantwoorden. "Wie rapporteert aan wie?" is slechts het begin. Veel organigrammen moeten ook laten zien wie een afdeling leidt, wie verlof goedkeurt voor een team en wie een rapport mag zien.

Schrijf de exacte vragen op die je schermen en permissiechecks zullen stellen. Als je de vragen niet kunt benoemen, eindig je met een schema dat er goed uitziet maar lastig te query'en is.

De beslissingen die alles vormgeven:

• Welke queries moeten snel zijn: directe manager, keten naar de CEO, volledige subtree onder een leidinggevende, of "iedereen in deze afdeling"?
• Is het een strikte boom (één manager) of een matrixorganisatie (meer dan één manager of lead)?
• Zijn afdelingen knooppunten in dezelfde hiërarchie als mensen, of een aparte attribuut (zoals department_id op elke persoon)?
• Kan iemand tot meerdere teams behoren (shared services, squads)?
• Hoe vloeien permissies: naar beneden in de boom, omhoog, of beide?

Die keuzes bepalen hoe "correcte" data eruitziet. Als Alex zowel Support als Onboarding leidt, werkt een enkele manager_id of de regel "één lead per team" misschien niet. Je hebt dan een koppel-tabel nodig (leider naar team) of een duidelijke policy zoals "één primair team, plus stippellijnteams".

Afdelingen zijn een andere splitsing. Als afdelingen nodes zijn, kun je uitdrukken "Afdeling A bevat Team B bevat Persoon C". Als afdelingen apart zijn, filter je met department_id = X, wat eenvoudiger is maar kan misgaan wanneer teams afdelingen overspannen.

Bepaal tenslotte permissies in gewone taal. "Een manager kan salaris zien van iedereen onder hen, maar niet van peers" is een regel die naar beneden in de boom gaat. "Iedereen kan hun managementketen zien" is een regel omhoog in de boom. Beslis dit vroeg, want het verandert welk hiërarchiemodel natuurlijk aanvoelt en welk model later dure queries afdwingt.

Adjacency-lijst: een eenvoudig schema voor managers en teams

Als je zo min mogelijk bewegende delen wilt, is een adjacency-lijst de klassieke startpunt. Elke persoon slaat een verwijzing naar hun directe manager op, en de boom ontstaat door die verwijzingen te volgen.

Een minimaal opzet ziet er zo uit:

create table departments (
  id bigserial primary key,
  name text not null unique
);

create table teams (
  id bigserial primary key,
  department_id bigint not null references departments(id),
  name text not null,
  unique (department_id, name)
);

create table employees (
  id bigserial primary key,
  full_name text not null,
  team_id bigint references teams(id),
  manager_id bigint references employees(id)
);

Je kunt ook de aparte tabellen overslaan en department_name en team_name als kolommen op employees houden. Dat is sneller om mee te beginnen, maar lastiger schoon te houden (typos, hernoemde teams en inconsistent rapporteren). Aparte tabellen maken filteren en permissie-regels makkelijker consistent uit te drukken.

Voeg vroeg beschermingsmaatregelen toe. Slechte hiërarchische data is pijnlijk om later te repareren. Laat in ieder geval zelf-management niet toe (manager_id <> id). Bepaal ook of een manager buiten hetzelfde team of dezelfde afdeling kan zitten en of je soft deletes of historische wijzigingen nodig hebt (voor auditing van rapportagelijnen).

Bij adjacency-lijsten zijn de meeste wijzigingen eenvoudige schrijfbewerkingen: een manager veranderen werkt employees.manager_id bij en het verplaatsen van teams werkt employees.team_id bij (vaak samen met de manager). Het nadeel is dat een kleine write grote downstream-effecten kan hebben. Rapportage-samenvattingen veranderen en elke regel "manager kan alle rapporten zien" moet nu de nieuwe keten volgen.

Deze eenvoud is de grootste kracht van de adjacency-lijst. Het zwakke punt verschijnt wanneer je vaak filtert op "iedereen onder deze manager", want dan vertrouw je meestal op recursieve queries om de boom telkens opnieuw te doorlopen.

Adjacency-lijst: veelvoorkomende queries voor filteren en rapportage

Met een adjacency-lijst worden veel nuttige organigramvragen recursieve queries. Als je organigrammen in PostgreSQL op deze manier modelleert, zijn dit de patronen die je constant zult gebruiken.

Directe rapporten (één niveau)

De eenvoudigste case is het directe team van een manager:

SELECT id, full_name, title
FROM employees
WHERE manager_id = $1
ORDER BY full_name;

Dit is snel en leesbaar, maar het gaat slechts één niveau naar beneden.

Keten van bevelvoering (omhoog)

Om te tonen aan wie iemand rapporteert (manager, manager's manager, enz.), gebruik je een recursieve CTE:

WITH RECURSIVE chain AS (
  SELECT id, full_name, manager_id, 0 AS depth
  FROM employees
  WHERE id = $1

  UNION ALL

  SELECT e.id, e.full_name, e.manager_id, c.depth + 1
  FROM employees e
  JOIN chain c ON e.id = c.manager_id
)
SELECT *
FROM chain
ORDER BY depth;

Dit ondersteunt goedkeuringen, escalatiepaden en breadcrumbs voor managers.

Volledige subtree (omlaag)

Om iedereen onder een leidinggevende te krijgen (alle niveaus), draai je de recursie om:

WITH RECURSIVE subtree AS (
  SELECT id, full_name, manager_id, department_id, 0 AS depth
  FROM employees
  WHERE id = $1

  UNION ALL

  SELECT e.id, e.full_name, e.manager_id, e.department_id, s.depth + 1
  FROM employees e
  JOIN subtree s ON e.manager_id = s.id
)
SELECT *
FROM subtree
ORDER BY depth, full_name;

Een veelvoorkomend rapport is "iedereen in afdeling X onder leidinggevende Y":

WITH RECURSIVE subtree AS (
  SELECT id, department_id
  FROM employees
  WHERE id = $1
  UNION ALL
  SELECT e.id, e.department_id
  FROM employees e
  JOIN subtree s ON e.manager_id = s.id
)
SELECT e.*
FROM employees e
JOIN subtree s ON s.id = e.id
WHERE e.department_id = $2;

Adjacency-lijstqueries kunnen riskant worden voor permissies omdat toegangstests vaak van het volledige pad afhangen (is de viewer een ancestor van deze persoon?). Als één endpoint de recursie vergeet of filters op de verkeerde plaats toepast, kun je rijen lekken. Let ook op datafouten zoals cycli en ontbrekende managers. Eén fout record kan recursie breken of verrassende resultaten teruggeven, dus permissiequeries hebben waarborgen en goede constraints nodig.

Closure-tabel: hoe het de hele hiërarchie opslaat

Een closure-tabel slaat elke ancestor-descendant-relatie op, niet alleen de directe managerverbinding. In plaats van stap voor stap door de boom te lopen, kun je vragen: "Wie valt onder deze leidinggevende?" en het volledige antwoord krijgen met een eenvoudige join.

Je houdt meestal twee tabellen: één voor nodes (mensen of teams) en één voor hiërarchiepaden.

-- nodes
employees (
  id bigserial primary key,
  name text not null,
  manager_id bigint null references employees(id)
)

-- closure
employee_closure (
  ancestor_id bigint not null references employees(id),
  descendant_id bigint not null references employees(id),
  depth int not null,
  primary key (ancestor_id, descendant_id)
)

De closure-tabel slaat paren zoals (Alice, Bob) op die betekenen "Alice is ancestor van Bob". Hij slaat ook een rij waar ancestor_id = descendant_id met depth = 0. Die zelfrij lijkt vreemd, maar maakt veel queries netter.

depth vertelt hoe ver twee knooppunten uit elkaar liggen: depth = 1 is een directe manager, depth = 2 is de manager van de manager, enz. Dit is belangrijk wanneer directe rapporten anders behandeld moeten worden dan indirecte.

Het belangrijkste voordeel is voorspelbare, snelle leesbewerkingen:

• Volledige subtree-opvragingen zijn snel (iedereen onder een director).
• Keten van bevelvoering is eenvoudig (alle managers boven iemand).
• Je kunt directe vs indirecte relaties scheiden met depth.

De kosten zitten in onderhoud bij updates. Als Bob van manager verandert van Alice naar Dana, moet je de closure-rijen voor Bob en iedereen onder Bob herbouwen. De gebruikelijke aanpak is: verwijder oude ancestor-paden voor die subtree en voeg daarna nieuwe paden in door de ancestors van Dana te combineren met elk knooppunt in Bobs subtree en de depth opnieuw te berekenen.

Closure-tabel: veelvoorkomende queries voor snel filteren

Een closure-tabel slaat elk ancestor-descendant-paar vooraf op (vaak als org_closure(ancestor_id, descendant_id, depth)). Dat maakt org-filters snel omdat de meeste vragen een enkele join worden.

Om iedereen onder een manager te vermelden, join je één keer en filter je op depth:

-- Descendants (iedereen in de subtree)
SELECT e.*
FROM employees e
JOIN org_closure c
  ON c.descendant_id = e.id
WHERE c.ancestor_id = :manager_id
  AND c.depth > 0;

-- Alleen directe rapporten
SELECT e.*
FROM employees e
JOIN org_closure c
  ON c.descendant_id = e.id
WHERE c.ancestor_id = :manager_id
  AND c.depth = 1;

Voor de keten van bevelvoering (alle ancestors van één werknemer), draai je de join om:

SELECT m.*
FROM employees m
JOIN org_closure c
  ON c.ancestor_id = m.id
WHERE c.descendant_id = :employee_id
  AND c.depth > 0
ORDER BY c.depth;

Filteren wordt voorspelbaar. Bijvoorbeeld: "alle mensen onder leider X, maar alleen in afdeling Y":

SELECT e.*
FROM employees e
JOIN org_closure c ON c.descendant_id = e.id
WHERE c.ancestor_id = :leader_id
  AND e.department_id = :department_id;

Omdat de hiërarchie vooraf is berekend, zijn tellingen ook eenvoudig (geen recursie). Dit helpt dashboards en permissie-gescopeerde totalen, en het werkt goed met paginering en zoeken omdat je ORDER BY, LIMIT/OFFSET en filters direct op de descendant-set kunt toepassen.

Hoe elk model permissies en toegangstests beïnvloedt

Een veelvoorkomende org-regel is simpel: een manager kan alles onder zich zien (en soms bewerken). Toegang is gebaseerd op descendants in de org-boom. Het schema dat je kiest verandert hoe vaak je de kosten betaalt om te bepalen "wie onder wie valt".

Bij een adjacency-lijst heeft de permissiecheck meestal recursie nodig. Als een gebruiker een pagina opent die 200 werknemers toont, bouw je typisch de descendant-set met een recursieve CTE en filter je doelrijen daarmee.

Met een closure-tabel kan dezelfde regel vaak worden gecontroleerd met een eenvoudige bestendigheidscheck: "Is de huidige gebruiker een ancestor van deze werknemer?" Zo ja, sta toe.

-- Closure-tabel permissiecheck (conceptueel)
SELECT 1
FROM org_closure c
WHERE c.ancestor_id = :viewer_id
  AND c.descendant_id = :employee_id
LIMIT 1;

Deze eenvoud telt wanneer je row-level security (RLS) introduceert, waarbij elke query automatisch een regel zoals "geef alleen rijen terug die de viewer mag zien" bevat. Bij adjacency-lijsten is de policy vaak recursief ingebed en lastiger te tunen. Bij een closure-tabel is de policy vaak een directe EXISTS(...)-check.

Randgevallen zijn waar permissielogica het vaakst faalt:

• Dotted-line reporting: één persoon heeft effectief twee managers.
• Assistants en gevolmachtigden: toegang is niet op hiërarchie gebaseerd, sla expliciete grants op (vaak met vervaldatum).
• Tijdelijke toegang: tijdgebonden permissies moeten niet in de org-structuur worden gebakken.
• Cross-team projecten: geef toegang via projectlidmaatschap, niet via managementketen.

Als je dit in AppMaster bouwt, past een closure-tabel vaak goed in een visueel datamodel en houdt de toegangstest zelf eenvoudig over web- en mobiele apps.

Afwegingen: snelheid, complexiteit en onderhoud

De grootste keuze is waarop je optimaliseert: eenvoudige schrijfbewerkingen en een klein schema, of snelle reads voor "wie valt onder deze manager" en permissiechecks.

Adjacency-lijsten houden de tabel klein en updates makkelijk. De kosten verschijnen bij reads: een volledige subtree betekent meestal recursie. Dat kan prima zijn als je organisatie klein is, je UI maar een paar niveaus laadt of hiërarchie-gebaseerde filters op slechts enkele plekken gebruikt worden.

Closure-tabellen draaien de afweging om. Reads worden snel omdat je "alle descendants" met reguliere joins kunt beantwoorden. Writes worden complexer omdat een verplaatsing of reorg veel relatie-rijen kan vereisen.

In het werkelijke leven ziet de afweging er meestal zo uit:

• Read-prestatie: adjacency heeft recursie nodig; closure is meestal joins en blijft snel als de organisatie groeit.
• Write-complexiteit: adjacency werkt één parent_id bij; closure werkt veel rijen bij voor een enkele verplaatsing.
• Datagrootte: adjacency groeit met mensen/teams; closure groeit met relaties (in het slechtste geval ongeveer N^2 voor een diepe boom).

Indexering is in beide modellen belangrijk, maar met verschillend doel:

• Adjacency-lijst: indexeer de ouderpointer (manager_id), plus veelgebruikte filters zoals een "active"-vlag.
• Closure-tabel: indexeer (ancestor_id, descendant_id) en ook descendant_id alleen voor veelvoorkomende opvragingen.

Een simpele regel: als je zelden op hiërarchie filtert en permissiechecks alleen "manager ziet directe rapporten" zijn, is een adjacency-lijst vaak voldoende. Als je regelmatig "iedereen onder VP X"-rapporten draait, filtert op afdelingstakken of hiërarchische permissies afdwingt over veel schermen, betalen closure-tabellen vaak terug voor het extra onderhoud.

Stapsgewijs: van adjacency-lijst naar closure-tabel migreren

Je hoeft niet op dag één tussen beide modellen te kiezen. Een veilige route is om je adjacency-lijst (manager_id of parent_id) te behouden en er naast een closure-tabel aan toe te voegen, en dan geleidelijk reads te migreren. Dit verlaagt risico terwijl je valideert hoe het nieuwe model zich gedraagt in echte queries en permissiechecks.

Begin met het maken van een closure-tabel (vaak org_closure) met kolommen zoals ancestor_id, descendant_id en depth. Houd die gescheiden van je bestaande employees of teams-tabel zodat je kunt backfillen en valideren zonder huidige features aan te raken.

Een praktische rollout:

• Maak de closure-tabel en indexen terwijl je de adjacency-lijst als bron van waarheid behoudt.
• Backfill closure-rijen uit de huidige managerrelaties, inclusief de self-rij (elk knooppunt is zijn eigen ancestor op depth 0).
• Valideer met steekproeven: kies een paar managers en bevestig dat dezelfde set ondergeschikten in beide modellen verschijnt.
• Schakel eerst leespaden om: rapporten, filters en hiërarchische permissies lezen eerst uit de closure-tabel voordat je writes verandert.
• Houd de closure up-to-date bij elke write (re-parent, huur, verplaats team). Als het stabiel is, vervang je recursie-gebaseerde queries.

Bij validatie, focus op gevallen die meestal toegangsregels breken: managerwissels, toplijsten en gebruikers zonder manager.

Als je dit in AppMaster bouwt, kun je de oude endpoints laten draaien terwijl je nieuwe toevoegt die uit de closure-tabel lezen en pas omzetten als de resultaten overeenkomen.

Veelgemaakte fouten die org-filters of permissies breken

De snelste manier om org-functionaliteit te breken is de hiërarchie inconsistent te laten worden. De data kan rij voor rij oké lijken, maar kleine fouten kunnen leiden tot verkeerde filters, trage pagina's of een permissielek.

Een klassiek probleem is per ongeluk een cyclus creëren: A beheert B, en later zet iemand B als manager van A (of een langere lus door 3–4 mensen). Recursieve queries kunnen dan oneindig lopen, dubbele rijen teruggeven of time-outs veroorzaken. Zelfs met een closure-tabel kunnen cycli ancestor/descendant-rijen verontreinigen.

Een ander veelvoorkomend issue is closure-drift: je verandert iemands manager, maar werkt alleen de directe relatie bij en vergeet de closure-rijen voor de subtree te herbouwen. Dan geven filters zoals "iedereen onder deze VP" een mix van oude en nieuwe structuren terug. Het is lastig te spotten omdat individuele profielen nog steeds correct lijken.

Organigrammen raken ook rommelig wanneer afdelingen en rapportagelijnen zonder duidelijke regels worden gemixt. Een afdeling is vaak een administratieve groepering, terwijl rapportagelijnen over managers gaan. Als je ze als dezelfde boom behandelt, kun je onverwacht gedrag krijgen zoals een "afdelingsmove" die per ongeluk toegang verandert.

Permissies falen het vaakst wanneer checks alleen naar de directe manager kijken. Als je toegang toestaat wanneer viewer is manager of employee, mis je de volledige keten. Het resultaat is óf te veel blokkeren (skip-level managers kunnen hun org niet zien) óf te veel delen (iemand krijgt toegang doordat die tijdelijk als directe manager is gezet).

Trage lijstpagina's komen vaak doordat recursieve filtering bij elke request wordt uitgevoerd (elke inbox, elke ticketlijst, elke werknemerszoekopdracht). Als dezelfde filter overal wordt gebruikt, wil je ofwel een voorgecompute pad (closure-tabel) of een gecachte set toegestane werknemer-IDs.

Enkele praktische waarborgen:

• Blokkeer cycli met validatie vóór opslag van managerwijzigingen.
• Bepaal wat "afdeling" betekent en houd het gescheiden van rapportage.
• Als je een closure-tabel gebruikt, rebuild descendant-rijen bij managerwijzigingen.
• Schrijf permissieregels voor de volledige keten, niet alleen de directe manager.
• Precompute org-scopes die door lijstpagina's worden gebruikt in plaats van recursie telkens opnieuw te berekenen.

Als je adminpanelen in AppMaster bouwt, behandel "verander manager" als een gevoelige workflow: valideer, update gerelateerde hiërarchische data en laat het pas dan filters en toegang beïnvloeden.

Snelle controles voordat je live gaat

Voordat je je organigram "klaar" noemt, zorg dat je toegang in gewone woorden kunt uitleggen. Als iemand vraagt: "Wie kan werknemer X zien, en waarom?", moet je naar één regel en één query (of view) kunnen wijzen die het bewijst.

Prestaties zijn de volgende realiteitstest. Bij een adjacency-lijst wordt "toon iedereen onder deze manager" een recursieve query waarvan de snelheid afhangt van diepte en indexering. Bij een closure-tabel zijn reads meestal snel, maar je moet je write-pad vertrouwen dat de tabel na elke wijziging correct blijft.

Een korte pre-release checklist:

• Kies één werknemer en traceer zichtbaarheid end-to-end: welke keten verleent toegang en welke rol weigert het.
• Benchmark een manager-subtree-query met je verwachte omvang (bijvoorbeeld 5 niveaus diep en 50.000 werknemers).
• Blokkeer slechte writes: voorkom cycli, zelf-management en verweesde nodes met constraints en transactionele checks.
• Test reorg-veiligheid: moves, merges, managerwijzigingen en rollback wanneer iets halverwege faalt.
• Voeg permissietests toe die zowel toegestane als geweigerde toegang voor realistische rollen (HR, manager, teamlead, support) controleren.

Een praktisch scenario om te valideren: een supportmedewerker kan alleen werknemers in hun toegewezen afdeling zien, terwijl een manager hun volledige subtree kan zien. Als je een organigram in PostgreSQL kunt modelleren en beide regels kunt bewijzen met tests, ben je dichtbij live gaan.

Als je dit als intern hulpmiddel in AppMaster bouwt, hou deze checks als geautomatiseerde tests rond de endpoints die org-lijsten en werknemersprofielen teruggeven, niet alleen rond databasequeries.

Voorbeeldscenario en volgende stappen

Stel je een bedrijf voor met drie afdelingen: Sales, Support en Engineering. Elke afdeling heeft twee teams en elk team heeft een lead. Sales Lead A kan kortingen goedkeuren voor hun team, Support Lead B kan alle tickets voor hun afdeling bekijken en de VP Engineering kan alles onder Engineering zien.

Dan gebeurt er een reorganisatie: één Support-team verhuist naar Sales en er wordt een nieuwe manager toegevoegd tussen de Sales-directeur en twee teamleads. De volgende dag vraagt iemand toegang: "Laat Jamie (een Sales-analist) alle klantaccounts voor de Sales-afdeling zien, maar niet Engineering."

Als je het organigram in PostgreSQL met een adjacency-lijst modelleert, is het schema eenvoudig, maar verschuift het werk naar je queries en permissiechecks. Filters zoals "iedereen onder Sales" vereisen meestal recursie. Zodra je goedkeuringen toevoegt (zoals "alleen managers in de keten kunnen goedkeuren"), gaan randgevallen na een reorganisatie belangrijk worden.

Met een closure-tabel betekent een reorganisatie meer schrijfwerk (ancestor/descendant-rijen updaten), maar wordt de leeszijde rechttoe rechtaan. Filteren en permissies worden vaak eenvoudige joins: "is deze gebruiker een ancestor van die werknemer?" of "zit dit team binnen deze afdelingstak?".

Dit zie je direct terug in schermen die mensen bouwen: people-pickers gegroepeerd op afdeling, goedkeuringsrouting naar de dichtstbijzijnde manager boven een aanvrager, admin-views voor afdelingsdashboards en audits die uitleggen waarom toegang op een bepaalde datum bestond.

Volgende stappen:

1. Schrijf de permissieregels in gewone taal (wie kan wat zien en waarom).
2. Kies een model dat past bij de meest voorkomende checks (snellere reads vs eenvoudigere writes).
3. Bouw een intern admin-hulpmiddel waarmee je reorganisaties, toegangaanvragen en goedkeuringen end-to-end kunt testen.

Als je snel org-bewuste adminpanelen en portals wilt bouwen, kan AppMaster (appmaster.io) praktisch zijn: het laat je PostgreSQL-ondersteunde data modelleren, goedkeuringslogica in een visueel Business Process implementeren en web- en native mobiele apps leveren vanaf dezelfde backend.