Organisationsdiagramme in PostgreSQL modellieren: Adjazenzlisten vs. Closure-Tabelle

Was ein Organisationsdiagramm unterstützen muss

Ein Organisationsdiagramm ist eine Karte, wer wem berichtet und wie Teams in Abteilungen zusammengefasst werden. Wenn du Organisationsdiagramme in PostgreSQL modellierst, speicherst du nicht nur ein manager_id auf jeder Person. Du unterstützt echte Arbeit: Orgausstieg, Berichte und Zugriffsregeln.

Die meisten Nutzer erwarten drei Dinge als sofortig: die Organisation erkunden, Personen finden und Ergebnisse auf „meinen Bereich“ filtern. Sie erwarten außerdem sichere Updates. Wenn ein Manager wechselt, sollte das Diagramm überall aktualisiert werden, ohne Berichte oder Berechtigungen zu zerstören.

In der Praxis muss ein gutes Modell ein paar wiederkehrende Fragen beantworten:

• Wie sieht die Befehlskette dieser Person bis ganz nach oben aus?
• Wer steht unter diesem Manager (Direktberichte und der ganze Subtree)?
• Wie gruppieren sich Personen in Teams und Abteilungen für Dashboards?
• Wie laufen Reorganisationsvorgänge ohne Störungen ab?
• Wer kann basierend auf der Organisationsstruktur was sehen?

Es wird komplexer als ein einfacher Baum, weil Organisationen sich oft ändern. Teams wechseln Abteilungen, Manager tauschen Gruppen, und manche Ansichten sind nicht rein „Personen berichten an Personen“. Zum Beispiel: Eine Person gehört zu einem Team, und Teams gehören zu Abteilungen. Berechtigungen fügen eine weitere Schicht hinzu: die Form der Organisation wird Teil deines Sicherheitsmodells, nicht nur ein Diagramm.

Einige Begriffe helfen, die Designs klar zu halten:

• Ein Knoten ist ein einzelnes Element in der Hierarchie (eine Person, ein Team oder eine Abteilung).
• Ein Parent ist der Knoten direkt darüber (ein Manager oder eine Abteilung, die ein Team besitzt).
• Ein Ahne ist jeder Knoten darüber in beliebiger Entfernung (der Manager deines Managers).
• Ein Nachkomme ist jeder Knoten darunter in beliebiger Entfernung (alle unter dir).

Beispiel: Wenn Sales unter einen neuen VP verschoben wird, sollten sofort zwei Dinge wahr sein. Dashboards filtern immer noch „alle Sales“, und die Berechtigungen des neuen VPs umfassen Sales automatisch.

Entscheidungen vor der Wahl eines Tabellen-Designs

Bevor du dich auf ein Schema festlegst, sei dir klar darüber, welche Fragen deine App jeden Tag beantworten muss. „Wer berichtet wem?“ ist nur der Anfang. Viele Organisationsdiagramme müssen auch zeigen, wer eine Abteilung leitet, wer Anträge genehmigt und wer einen Bericht sehen darf.

Schreibe die genauen Fragen auf, die deine Bildschirme und Berechtigungsprüfungen stellen werden. Wenn du die Fragen nicht benennen kannst, endest du mit einem Schema, das zwar richtig aussieht, aber schwer zu queryen ist.

Die Entscheidungen, die alles formen:

• Welche Abfragen müssen schnell sein: direkter Manager, Kette bis zum CEO, ganzer Subtree unter einer Führungskraft oder „alle in dieser Abteilung“?
• Ist es ein strikter Baum (ein Manager) oder eine Matrixorganisation (mehrere Manager/Leads)?
• Sind Abteilungen Knoten in derselben Hierarchie wie Personen oder ein separates Attribut (z. B. department_id auf jeder Person)?
• Kann jemand mehreren Teams angehören (Shared Services, Squads)?
• Wie fließen Berechtigungen: nach unten, nach oben oder beides?

Diese Entscheidungen definieren, wie „korrekte“ Daten aussehen. Wenn Alex sowohl Support als auch Onboarding leitet, funktioniert ein einzelnes manager_id oder die Regel „ein Lead pro Team“ möglicherweise nicht. Du benötigst dann eine Join-Tabelle (Lead zu Team) oder eine klare Policy wie „ein primäres Team plus Dotted-Line-Teams“.

Abteilungen sind ein weiterer Verzweigungspunkt. Wenn Abteilungen Knoten sind, kannst du ausdrücken „Abteilung A enthält Team B enthält Person C“. Wenn Abteilungen separat sind, filterst du mit department_id = X, was einfacher ist, aber schwierig werden kann, wenn Teams Abteilungen überschreiten.

Definiere schließlich Berechtigungen in klarer Sprache. „Ein Manager kann das Gehalt aller unter ihm sehen, aber nicht das seiner Peers“ ist eine Abwärtsregel. „Jeder kann seine Managementkette sehen“ ist eine Aufwärtsregel. Entscheide das früh, denn es ändert, welches Hierarchiemodell sich natürlich anfühlt und welches später teure Abfragen erzwingt.

Adjazenzliste: ein einfaches Schema für Manager und Teams

Wenn du möglichst wenige bewegliche Teile willst, ist die Adjazenzliste der klassische Ausgangspunkt. Jede Person speichert einen Zeiger auf ihren direkten Manager, und der Baum entsteht durch das Folgen dieser Zeiger.

Eine minimale Struktur sieht so aus:

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)
);

Du kannst auch die separaten Tabellen weglassen und department_name und team_name als Spalten in employees speichern. Das ist schneller zum Start, aber schwerer sauber zu halten (Tippfehler, umbenannte Teams, inkonsistente Berichte). Separate Tabellen machen Filter und Berechtigungsregeln leichter konsistent ausdrückbar.

Führe von Anfang an Schutzmechanismen ein. Schlechte Hierarchiedaten sind später schwer zu reparieren. Mindestens sollte Selbstverwaltung verhindert werden (manager_id <> id). Entscheide außerdem, ob ein Manager außerhalb desselben Teams oder derselben Abteilung sein darf und ob du Soft-Deletes oder historische Änderungen (für Auditing von Berichtslinien) brauchst.

Bei Adjazenzlisten sind die meisten Änderungen einfache Writes: einen Manager ändern aktualisiert employees.manager_id, ein Team verschieben aktualisiert employees.team_id (oft zusammen mit dem Manager). Der Haken ist, dass ein kleiner Write große Auswirkungen haben kann. Rollups in Berichten ändern sich, und jede Regel „Manager kann alle Berichte sehen“ muss jetzt der neuen Kette folgen.

Diese Einfachheit ist die größte Stärke der Adjazenzliste. Ihre Schwäche zeigt sich, wenn du häufig nach „alle unter diesem Manager“ filterst, weil du in der Regel rekursive Abfragen verwenden musst, um den Baum jedes Mal zu durchlaufen.

Adjazenzliste: häufige Abfragen für Filter und Berichte

Mit einer Adjazenzliste werden viele nützliche Fragen zu rekursiven Abfragen. Wenn du Organisationsdiagramme in PostgreSQL so modellierst, sind das Muster, die du konstant nutzen wirst.

Direkte Berichte (eine Ebene)

Der einfachste Fall ist das sofortige Team eines Managers:

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

Das ist schnell und lesbar, geht aber nur eine Ebene herunter.

Befehlskette (aufwärts)

Um zu zeigen, wem jemand berichtet (Manager, Manager des Managers usw.), verwende eine rekursive 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;

Das unterstützt Genehmigungen, Eskalationspfade und Breadcrumbs für Manager.

Voller Subtree (abwärts)

Um alle unter einer Führungskraft zu erhalten (über alle Ebenen), kehre die Rekursion um:

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;

Ein häufiger Bericht ist „alle in Abteilung X unter Führungskraft 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;

Adjazenzlisten-Abfragen können für Berechtigungen riskant werden, weil Zugriffskontrollen oft vom vollständigen Pfad abhängen (ist der Betrachter ein Ahne dieser Person?). Wenn ein Endpunkt die Rekursion vergisst oder Filter an der falschen Stelle anwendet, kannst du Zeilen leaken. Achte auch auf Datenprobleme wie Zyklen und fehlende Manager. Ein fehlerhafter Datensatz kann Rekursionen brechen oder überraschende Ergebnisse liefern, daher brauchen Berechtigungsabfragen Schutzmaßnahmen und gute Constraints.

Closure-Tabelle: wie sie die ganze Hierarchie speichert

Eine Closure-Tabelle speichert jede Ahnen-Nachkommen-Beziehung, nicht nur den direkten Managerlink. Anstatt den Baum Schritt für Schritt zu durchlaufen, kannst du fragen: „Wer steht unter dieser Führungskraft?“ und die vollständige Antwort mit einem einfachen Join erhalten.

Du hast üblicherweise zwei Tabellen: eine für die Knoten (Personen oder Teams) und eine für die Hierarchie-Pfade.

-- 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)
)

Die Closure-Tabelle speichert Paare wie (Alice, Bob), was „Alice ist ein Ahne von Bob“ bedeutet. Sie speichert auch eine Zeile, in der ancestor_id = descendant_id mit depth = 0. Diese Selbstzeile wirkt zunächst seltsam, macht aber viele Abfragen sauberer.

depth sagt dir, wie weit zwei Knoten auseinander sind: depth = 1 ist ein direkter Manager, depth = 2 ist der Manager des Managers usw. Das ist wichtig, wenn direkte Berichte anders behandelt werden sollen als indirekte.

Der Hauptvorteil sind vorhersehbare, schnelle Leszugriffe:

• Ganze Subtree-Lookups sind schnell (alle unter einem Direktor).
• Befehlsketten sind einfach (alle Manager über jemandem).
• Du kannst direkte vs. indirekte Beziehungen mit depth trennen.

Die Kosten liegen in der Wartung bei Updates. Wenn Bob seinen Manager von Alice zu Dana ändert, musst du Closure-Zeilen für Bob und alle unter Bob neu aufbauen. Der typische Ansatz ist: alte Ahnenpfade für diesen Subtree löschen und dann neue Pfade einfügen, indem du Danas Ahnen mit jedem Knoten von Bobs Subtree kombinierst und die Depth neu berechnest.

Closure-Tabelle: häufige Abfragen für schnelles Filtern

Eine Closure-Tabelle speichert jedes Ahne-Nachkomme-Paar vorab (oft als org_closure(ancestor_id, descendant_id, depth)). Das macht Orga-Filter schnell, weil die meisten Fragen zu einem einzigen Join werden.

Um alle unter einem Manager aufzulisten, einmal joinen und nach depth filtern:

-- Descendants (everyone in the 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;

-- Direct reports only
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;

Für die Befehlskette (alle Ahnen eines Mitarbeiters) dreh den Join um:

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;

Filtering wird dadurch vorhersehbar. Beispiel: „alle Personen unter Leiter X, aber nur in Abteilung 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;

Weil die Hierarchie vorcomputiert ist, sind auch Zählungen unkompliziert (keine Rekursion). Das hilft Dashboards und bereichsbezogenen Totals und spielt gut mit Pagination und Suche, da du ORDER BY, LIMIT/OFFSET und Filter direkt auf die Nachkommensmenge anwenden kannst.

Wie sich jedes Modell auf Berechtigungen und Zugriffskontrollen auswirkt

Eine übliche Organisationsregel ist einfach: Ein Manager kann alles unter sich sehen (und manchmal bearbeiten). Das Schema, das du wählst, ändert, wie oft du die Kosten dafür bezahlst, zu ermitteln, „wer unter wem ist“.

Bei Adjazenzlisten braucht die Berechtigungsprüfung meist Rekursion. Wenn ein Benutzer eine Seite öffnet, die 200 Mitarbeiter listet, baust du typischerweise die Nachkommensmenge mit einer rekursiven CTE und filterst Zielzeilen dagegen.

Mit einer Closure-Tabelle lässt sich dieselbe Regel oft mit einem einfachen Existenztest prüfen: „Ist der aktuelle Benutzer ein Ahne dieses Mitarbeiters?“ Wenn ja, erlauben.

-- Closure table permission check (conceptual)
SELECT 1
FROM org_closure c
WHERE c.ancestor_id = :viewer_id
  AND c.descendant_id = :employee_id
LIMIT 1;

Diese Einfachheit ist wichtig, wenn du Row-Level Security (RLS) einführst, bei der jede Abfrage automatisch eine Regel wie „nur die Zeilen zurückgeben, die der Betrachter sehen darf“ enthält. Bei Adjazenzlisten bettet die Policy oft Rekursion ein und ist schwerer zu tunen. Bei einer Closure-Tabelle ist die Policy oft ein geradliniges EXISTS (...).

Randfälle sind dort, wo Berechtigungslogik am häufigsten bricht:

• Dotted-Line-Reporting: Eine Person hat effektiv zwei Manager.
• Assistenten und Delegierte: Der Zugriff basiert nicht auf der Hierarchie, also speichere explizite Grants (oft mit Ablaufdatum).
• Temporärer Zugriff: Zeitlich begrenzte Berechtigungen sollten nicht in die Organisationsstruktur eingebettet werden.
• Cross-Team-Projekte: Zugriff per Projektmitgliedschaft gewähren, nicht per Managementkette.

Wenn du das in AppMaster baust, lässt sich eine Closure-Tabelle oft sauber in ein visuelles Datenmodell abbilden und hält die Zugriffskontrolle selbst über Web- und Mobile-Apps einfach.

Abwägungen: Geschwindigkeit, Komplexität und Wartung

Die größte Wahl ist, worauf du optimierst: einfache Writes und ein kleines Schema oder schnelle Reads für „wer ist unter diesem Manager“ und Berechtigungsprüfungen.

Adjazenzlisten halten die Tabelle klein und Updates einfach. Die Kosten zeigen sich bei Reads: ein kompletter Subtree bedeutet Rekursion. Das kann in Ordnung sein, wenn deine Organisation klein ist, deine UI nur wenige Ebenen lädt oder hierarchiebasierte Filter nur an wenigen Stellen genutzt werden.

Closure-Tabellen drehen den Trade-off um. Reads werden schnell, weil du „alle Nachkommen“ mit normalen Joins beantworten kannst. Writes werden komplizierter, weil ein Move oder Reorg viele Relationship-Zeilen einfügen oder löschen kann.

Im Alltag sieht der Trade-off oft so aus:

• Leseleistung: Adjazenz benötigt Rekursion; Closure nutzt überwiegend Joins und bleibt schnell, wenn die Organisation wächst.
• Schreibkomplexität: Adjazenz aktualisiert ein parent_id; Closure aktualisiert viele Zeilen bei einem einzelnen Move.
• Datenmenge: Adjazenz wächst mit Personen/Teams; Closure wächst mit Beziehungen (im schlimmsten Fall ungefähr N^2 für einen tiefen Baum).

Indexierung ist in beiden Modellen wichtig, aber das Ziel unterscheidet sich:

• Adjazenzliste: indexiere den Elternzeiger (manager_id) sowie häufige Filter wie ein active-Flag.
• Closure-Tabelle: indexiere (ancestor_id, descendant_id) und zusätzlich descendant_id allein für häufige Lookups.

Eine einfache Regel: Wenn du selten nach Hierarchie filterst und Berechtigungsprüfungen nur „Manager sieht direkte Berichte“ sind, reicht oft eine Adjazenzliste. Wenn du regelmäßig „alle unter VP X“ Berichte erstellst, nach Abteilungsbäumen filterst oder hierarchische Berechtigungen über viele Bildschirme durchsetzt, zahlen sich Closure-Tabellen für die zusätzlichen Wartungskosten aus.

Schritt für Schritt: Von Adjazenzliste zu Closure-Tabelle wechseln

Du musst dich nicht am ersten Tag für ein Modell entscheiden. Ein sicherer Weg ist, die Adjazenzliste (manager_id oder parent_id) zu behalten und daneben eine Closure-Tabelle hinzuzufügen, dann die Lesewege nach und nach umzuziehen. Das senkt das Risiko, während du validierst, wie sich das neue Modell in realen Abfragen und Berechtigungsprüfungen verhält.

Beginne mit dem Erstellen einer Closure-Tabelle (oft org_closure genannt) mit Spalten wie ancestor_id, descendant_id und depth. Halte sie getrennt von deiner bestehenden employees- oder teams-Tabelle, sodass du backfillen und validieren kannst, ohne aktuelle Features zu berühren.

Ein praktischer Rollout:

• Erstelle die Closure-Tabelle und Indizes, während die Adjazenzliste weiterhin Quelle der Wahrheit bleibt.
• Backfille Closure-Zeilen aus den aktuellen Manager-Beziehungen, einschließlich der Selbstzeilen (jeder Knoten ist sein eigener Ahne mit depth = 0).
• Validiere mit Stichproben: Wähle ein paar Manager und bestätige, dass dieselbe Menge von Untergebenen in beiden Modellen erscheint.
• Schalte zuerst die Lesewege um: Berichte, Filter und hierarchische Berechtigungen lesen zuerst aus der Closure-Tabelle, bevor du die Writes änderst.
• Halte die Closure-Tabelle bei jedem Write aktuell (Reparent, Hire, Team-Move). Sobald stabil, verabschiede rekursive Abfragen.

Beim Validieren konzentriere dich auf Fälle, die üblicherweise Zugriff fehlerhaft machen: Managerwechsel, Top-Level-Führungskräfte und Nutzer ohne Manager.

Wenn du das in AppMaster baust, kannst du die alten Endpunkte weiterlaufen lassen, während du neue hinzufügst, die aus der Closure-Tabelle lesen, und dann umschalten, sobald die Ergebnisse übereinstimmen.

Häufige Fehler, die Filter oder Berechtigungen brechen

Der schnellste Weg, Orga-Funktionen zu ruinieren, ist, die Hierarchie inkonsistent werden zu lassen. Die Daten mögen auf Zeilenebene korrekt aussehen, aber kleine Fehler können falsche Filter, langsame Seiten oder eine Berechtigungslücke verursachen.

Ein klassisches Problem ist das versehentliche Erzeugen eines Zyklus: A verwaltet B, und später setzt jemand B als Manager von A (oder eine längere Schleife durch 3–4 Personen). Rekursive Abfragen können endlos laufen, doppelte Zeilen liefern oder timeouten. Selbst mit einer Closure-Tabelle können Zyklen Ahnen-/Nachkommen-Zeilen verunreinigen.

Ein weiteres häufiges Problem ist Closure-Drift: Du änderst den Manager einer Person, aktualisierst aber nur die direkte Beziehung und vergisst, die Closure-Zeilen für den Subtree neu zu berechnen. Dann liefern Filter wie „alle unter diesem VP“ eine Mischung aus alter und neuer Struktur. Das ist schwer zu erkennen, weil einzelne Profilseiten weiterhin korrekt aussehen.

Organisationsdiagramme werden auch unordentlich, wenn Abteilungen und Berichtslinien ohne klare Regeln vermischt werden. Eine Abteilung ist oft eine administrative Gruppierung, während Berichtslinien Manager betreffen. Wenn du sie als denselben Baum behandelst, kannst du seltsames Verhalten bekommen, wie dass eine „Abteilungsverschiebung“ unerwartet Zugriff ändert.

Berechtigungen scheitern am häufigsten, wenn Prüfungen nur den direkten Manager betrachten. Erlaubst du Zugriff nur, wenn viewer is manager of employee, verpasst du die gesamte Kette. Das Ergebnis ist entweder Über-Blockieren (Skip-Level-Manager können ihre Organisation nicht sehen) oder Über-Freigabe (jemand erhält Zugriff durch einen temporär gesetzten direkten Manager).

Langsame Listen-Seiten entstehen oft, weil bei jeder Anfrage rekursive Filter ausgeführt werden (Inbox, Ticketlisten, Mitarbeitersuche). Wenn derselbe Filter überall verwendet wird, willst du entweder einen vorcomputierten Pfad (Closure-Tabelle) oder eine gecachte Menge erlaubter Mitarbeiter-IDs.

Ein paar praktische Schutzmaßnahmen:

• Verhindere Zyklen mit Validierung vor dem Speichern von Manageränderungen.
• Definiere klar, was „Abteilung“ bedeutet, und trenne es von der Berichtslinie.
• Wenn du eine Closure-Tabelle verwendest, baue die Nachkommen-Zeilen bei Manageränderungen neu auf.
• Schreibe Berechtigungsregeln für die ganze Kette, nicht nur für den direkten Manager.
• Precompute die organisatorischen Scopes, die in Listen-Seiten verwendet werden, statt Rekursionen bei jeder Anfrage neu zu berechnen.

Wenn du Admin-Panels in AppMaster baust, behandle „Manager ändern“ als sensitiven Workflow: validiere, aktualisiere verwandte Hierarchiedaten und lass erst danach Filter und Zugriff davon betroffen sein.

Schnellchecks vor dem Release

Bevor du dein Organisationsdiagramm als „fertig" deklarierst, stelle sicher, dass du Zugriff in einfachen Worten erklären kannst. Wenn jemand fragt: „Wer kann Mitarbeiter X sehen und warum?“, solltest du auf eine Regel und eine Abfrage (oder View) verweisen können, die das beweist.

Performance ist die nächste Realität. Bei einer Adjazenzliste wird „zeige mir alle unter diesem Manager“ eine rekursive Abfrage, deren Geschwindigkeit von Tiefe und Indizierung abhängt. Bei einer Closure-Tabelle sind Reads meist schnell, aber du musst deinem Schreibpfad vertrauen, dass er die Tabelle nach jeder Änderung korrekt hält.

Eine kurze Pre-Ship-Checkliste:

• Wähle einen Mitarbeiter und verfolge die Sichtbarkeit Ende-zu-Ende: welche Kette gewährt Zugriff und welche Rolle verweigert ihn.
• Benchmark eine Manager-Subtree-Abfrage mit deiner erwarteten Größe (z. B. 5 Ebenen tief und 50.000 Mitarbeiter).
• Blockiere fehlerhafte Writes: Verhindere Zyklen, Selbstverwaltung und Waisen-Knoten mit Constraints und Transaktionsprüfungen.
• Teste Reorg-Sicherheit: Moves, Merges, Manager-Änderungen und Rollback, wenn etwas mitten im Prozess fehlschlägt.
• Füge Berechtigungstests hinzu, die erlaubten und verweigerten Zugriff für realistische Rollen (HR, Manager, Teamlead, Support) absichern.

Ein praktisches Szenario zur Validierung: Ein Support-Agent darf nur Mitarbeiter in seiner zugewiesenen Abteilung sehen, während ein Manager seinen kompletten Subtree sehen kann. Wenn du Organisationsdiagramme in PostgreSQL modellieren kannst und beide Regeln mit Tests nachweisen kannst, bist du nahe am Release.

Wenn du das als internes Tool in AppMaster entwickelst, behalte diese Checks als automatische Tests rund um die Endpunkte, die Organisationslisten und Mitarbeiterprofile zurückgeben, nicht nur als reine Datenbankabfragen.

Beispielszenario und nächste Schritte

Stell dir eine Firma mit drei Abteilungen vor: Sales, Support und Engineering. Jede Abteilung hat zwei Teams, und jedes Team hat einen Lead. Sales Lead A kann Rabatte für sein Team genehmigen, Support Lead B kann alle Tickets seiner Abteilung sehen und der VP Engineering sieht alles unter Engineering.

Dann passiert eine Reorg: Ein Support-Team verschiebt sich unter Sales, und ein neuer Manager wird zwischen Sales Director und zwei Teamleads eingefügt. Am nächsten Tag stellt jemand eine Zugriffsanforderung: „Lass Jamie (ein Sales-Analyst) alle Kundenkonten für die Sales-Abteilung sehen, aber nicht Engineering."

Wenn du Organisationsdiagramme in PostgreSQL mit einer Adjazenzliste modellierst, ist das Schema einfach, aber die Arbeit verlagert sich in deine Abfragen und Berechtigungsprüfungen. Filter wie „alle unter Sales“ benötigen in der Regel Rekursion. Sobald du Genehmigungen hinzufügst (z. B. „nur Manager in der Kette dürfen genehmigen"), werden Randfälle nach einer Reorg relevant.

Mit einer Closure-Tabelle bedeutet ein Reorg mehr Schreibarbeit (Ahnen-/Nachkommen-Zeilen aktualisieren), aber die Lese-Seite wird einfach. Filter und Berechtigungen werden oft zu simplen Joins: „ist dieser Benutzer ein Ahne dieses Mitarbeiters?“ oder „ist dieses Team innerhalb des Abteilungs-Subtrees X?".

Das zeigt sich direkt in den Bildschirmen, die gebaut werden: People-Picker, die auf eine Abteilung begrenzt sind, Genehmigungs-Routing an den nächstgelegenen Manager über einem Antragsteller, Admin-Views für Abteilungsdashboards und Audits, die erklären, warum ein Zugriff an einem bestimmten Datum bestand.

Nächste Schritte:

1. Schreibe die Berechtigungsregeln in Klartext (wer kann was sehen und warum).
2. Wähle ein Modell, das zu den häufigsten Prüfungen passt (schnelle Reads vs. einfachere Writes).
3. Baue ein internes Admin-Tool, mit dem sich Reorgs, Zugriffsanforderungen und Genehmigungen Ende-zu-Ende testen lassen.

Wenn du diese organisationsbewussten Admin-Panels und Portale schnell bauen willst, kann AppMaster (appmaster.io) praktisch sein: Es erlaubt dir, PostgreSQL-gestützte Daten zu modellieren, Genehmigungslogik visuell als Business Process zu implementieren und Web- sowie native Mobile-Apps aus demselben Backend auszuliefern.