Daten passend zum Anwendungsfall speichern

Daten passend zum Anwendungsfall speichern

0:00 Bei der Frage nach dem Speicher greifen die meisten Teams sofort zur Technik: Key-Value oder Datenbank? Dabei kommt eine Frage davor, und sie wird viel zu selten gestellt — muss die App diese Daten überhaupt selbst speichern? Sehr oft lautet die Antwort nein, weil Jira die Information längst kennt. Dieses Modul geht deshalb in dieser Reihenfolge vor: erst der Ort, dann die Technik, dann das Modell, dann die Grenzen.

0:24 Am Ende speichert Klarpfad zum ersten Mal wirklich dauerhaft — und Sie können begründen, warum ausgerechnet so.

Daten passend zum Anwendungsfall speichern

0:31 Am Vormittag haben wir die Verbindung zwischen Oberfläche und Backend gebaut. Jetzt geht es um das, was hinter dem Resolver liegt. Wir schauen uns die drei möglichen Orte an, die Speicherarten der Plattform, die Frage nach Schlüsseln und Modell — und zum Schluss die Grenzen, die man kennen sollte, bevor die erste Kundin sie findet.

Wo Daten liegen dürfen

0:50 Beginnen wir mit der Frage, die vor allen technischen Entscheidungen steht: Wo dürfen und sollen diese Daten überhaupt liegen? Es gibt genau drei Orte, und sie unterscheiden sich weniger in der Technik als in der Verantwortung. Im Produkt selbst — also als Vorgangsfeld oder Seiteninhalt. Im Forge-eigenen Speicher, getrennt je Installation, innerhalb der Plattform. Oder außerhalb, in einem eigenen System.

1:14 Mit jedem Schritt nach außen übernehmen Sie mehr Verantwortung: für Datenschutz, für Verfügbarkeit, für die Frage, was passiert, wenn ein Kunde die App deinstalliert. Das ist keine Warnung, sondern eine Rechnung, die man vorher aufmachen sollte. Lesen Sie diese Schichtung als Reihenfolge der Prüfung, nicht als Auswahl. Ganz oben das Produkt: Alles, was Jira ohnehin kennt, muss die App nicht noch einmal speichern.

1:39 In der Mitte Forge: der natürliche Ort für App-eigene Daten, die es ohne die App nicht gäbe. Und unten die Welt außerhalb, mit Egress-Regel und Datenschutzfrage im Gepäck. Der Trick besteht darin, von oben nach unten zu gehen und bei der ersten Schicht stehen zu bleiben, die trägt. Die meisten Architekturprobleme entstehen, wenn man unten anfängt.

2:00 Vier Gründe, und der erste ist der stärkste: Was Jira kennt, muss die App nicht spiegeln — und vor allem nicht synchron halten. Jede Kopie ist ein Versprechen, sie aktuell zu halten, und dieses Versprechen wird irgendwann gebrochen. Der zweite Punkt ist zweischneidig: Forge-Speicher endet mit der Deinstallation. Das ist sauber, wenn jemand die App loswerden will.

2:21 Es ist ein böses Erwachen, wenn eine Abteilung dort drei Jahre Entscheidungen gesammelt hat. Sprechen Sie das offen an, bevor es jemand anderes tut. Der erste Punkt ist der häufigste Anfängerfehler und sieht zunächst clever aus: Vorgangsfelder in den App-Speicher kopieren, damit die Anzeige schneller ist. Drei Wochen später zeigt die App Werte, die es in Jira nicht mehr gibt. Der zweite gehört ins Gespräch mit dem Datenschutz, nicht in den Code-Review.

2:47 Und der dritte ist der, den ich Ihnen als Frage ans Herz lege: Was passiert bei der Deinstallation — und wer weiß das außer Ihnen?

Key-Value Store und Entity Store

2:55 Gehen wir davon aus, die Daten gehören tatsächlich in den Forge-Speicher. Dann stellt sich die nächste Frage: in welchen? Der Unterschied lässt sich an einem Büro erklären. Der Key-Value Store ist das Schließfach: Sie legen etwas unter einer Nummer ab und holen es unter derselben Nummer wieder. Schnell, einfach, und wer die Nummer nicht kennt, findet nichts.

3:17 Der Entity Store ist der Aktenschrank mit Registern: Einträge haben Attribute, und über Indizes können Sie nach verschiedenen Merkmalen suchen. Und Forge SQL ist die Datenbank für Fälle, in denen Beziehungen und Auswertungen im Vordergrund stehen. Die Wahl hängt an einer einzigen Frage: Wonach suchen Sie später? Fünf Zeilen für den kompletten Umgang — einfacher geht es kaum.

3:39 Interessanter als die Aufrufe ist die Zeile darüber: der Schlüssel, zusammengesetzt aus einem Präfix und der Vorgangskennung. Diese Zusammensetzung ist bereits Ihr Datenmodell, auch wenn es nicht so aussieht. Und die Fußzeile nennt eine Eigenschaft, die man kennen muss: Die Ablage ist je Installation getrennt. Dieselbe App auf zwei Sites teilt keine Daten.

4:01 Das ist Mandantentrennung, die Sie geschenkt bekommen — und zugleich der Grund, warum es keine globale Auswertung über alle Kunden gibt. Drei Zeilen, und die dritte Spalte ist die wichtigste. Beim Schließfach lautet die Grenze: Abfrage nur über den Schlüssel. Wer alle Entscheidungen mit Status offen über alle Vorgänge sehen will, kann das dort nicht — er müsste alles laden und selbst filtern. Genau dann lohnt der Entity Store.

4:26 Und die Fußzeile nennt die Größenordnung, in der Sie sich bewegen: zwanzig Entitäten je App, bis zu fünfzig Attribute, bis zu sieben eigene Indizes. Das ist großzügig für eine Erweiterung und eng für ein eigenes Produkt — und diese Unterscheidung ist genau die Frage, die Sie sich stellen sollten. Der erste Punkt beschreibt einen schleichenden Verfall: Eine Liste im Schließfach wächst, und jede Abfrage lädt alles.

4:51 Das ist bei zehn Einträgen elegant und bei tausend ein Problem — und dazwischen merkt es niemand. Der zweite ist der umgekehrte Fehler, der Aufwand ohne Gegenwert erzeugt. Und der dritte beschreibt, wie die Wahl in Wahrheit oft zustande kommt: nach Vertrautheit. Die bessere Frage steht auf der vorigen Folie — wonach wird gesucht?

Datenmodell und Schlüssel

5:12 Jetzt zum Modell selbst. Und dabei zu einer Erkenntnis, die viele überrascht: Der Schlüssel ist die wichtigste Entwurfsentscheidung. Im Schließfach bestimmt der Schlüssel, was später möglich ist. Ein sprechender Aufbau aus Präfix und fachlicher Kennung hat sich bewährt — er macht die Ablage lesbar und erlaubt gezielte Zugriffe.

5:31 Im Entity Store übernehmen Attribute und Indizes diese Rolle: Die Partition bestimmt, wonach gebündelt wird, der Bereich, wonach sortiert und eingegrenzt werden kann. In beiden Fällen gilt derselbe Grundsatz wie in jeder Datenbank: Sie entwerfen nicht für die Anzeige, Sie entwerfen für die Abfrage. Bemerkenswert ist hier vor allem, wo das steht: im Manifest. Ihr Datenmodell ist Teil der Beschreibung Ihrer App, nicht ein Schema irgendwo im Code.

5:58 Sie benennen die Entität, die Attribute mit ihren Typen und die Indizes. Der Index unten sagt: Bündle nach Vorgang. Damit ist die Abfrage „alle Entscheidungen zu diesem Vorgang" effizient möglich. Die Fußzeile nennt die harten Grenzen für einen einzelnen Eintrag — rund 240 Kilobyte und eine Verschachtelungstiefe von 31. Wer dort anstößt, hat meistens kein Speicherproblem, sondern ein Modellproblem.

6:24 Der erste Schritt ist der, der am meisten spart: die Abfragen aufschreiben, bevor das Modell entsteht. Zwei Sätze genügen oft. Schritt drei wird gern übersprungen und rächt sich bei der ersten Erweiterung — jede Schemaänderung braucht einen Weg für die Einträge, die es schon gibt. Schritt vier ist der, über den wir gestern schon beim Formular gesprochen haben, jetzt eine Ebene tiefer: Wiederholtes Schreiben desselben Eintrags darf keinen zweiten erzeugen.

6:50 Und Schritt fünf ist der Realitätstest — Testdaten mit realistischem Wachstum, nicht drei Beispiele. Der erste Punkt ist der elegante Fehler: Der Schlüssel enthält den Anzeigetitel. Das liest sich schön, bis jemand den Titel ändert — dann ist der alte Eintrag verwaist und ein neuer entsteht. Der zweite ist die fehlende Migration: Ein neues Attribut fehlt in alten Einträgen, und die Anzeige bricht an einer Stelle, die niemand vermutet.

7:15 Und der dritte ist der doppelte Eintrag aus dem Doppelklick — diesmal ohne Formular, dafür mit der Erkenntnis, dass die Kennung vom Backend vergeben werden muss.

Grenzen und Kosten

7:25 Bleibt der unangenehme Teil, den man gern ans Ende schiebt: Grenzen und das, was der Betrieb kostet. Der wichtigste Satz dieser Folie steht in der Mitte: Überschreitungen führen nicht zu einem langsameren System, sondern zu Fehlern. Das unterscheidet eine Plattform von einem eigenen Server. Ein eigener Server wird zäh, und man hat Wochen, um zu reagieren.

7:47 Hier greifen Grenzen abrupt — die App funktioniert, und dann funktioniert sie nicht mehr. Dazu kommt, dass Speicher und Aufrufe Verbrauch erzeugen, der im Betrieb sichtbar wird. Das ist kein Kleingedrucktes, sondern Teil der Architekturentscheidung. Diese vier Punkte laufen auf eine Einsicht hinaus: Ein funktionierender Prototyp sagt nichts über den Betrieb. Er sagt nur, dass die Logik stimmt.

8:10 Ob sie bei zehntausend Einträgen stimmt, haben Sie damit nicht geprüft. Der dritte Punkt ist der teuerste: Ein Wechsel des Speichers ist später keine Umstellung, sondern eine Migration — mit Ausfallzeit, Prüfung und Nacharbeit. Und der vierte ist der leiseste: Kosten entstehen still, solange niemand hinsieht. Am fünften Tag schauen wir uns an, wo man sie sieht.

8:32 Der erste Punkt ist einer, der praktisch jede App betrifft: Historie wird gesammelt, weil Löschen sich falsch anfühlt — und niemand hat je einen Plan für das Aufräumen gemacht. Der zweite ist der technische Klassiker: Alles laden und im Frontend filtern. Das ist bequem, verlagert die Arbeit an die falsche Stelle und treibt gleichzeitig Aufrufzahlen und Datenmenge.

8:53 Und der dritte beschreibt den typischen Zeitpunkt, zu dem Grenzen geprüft werden — nämlich dann, wenn es schon zu spät ist.

Übung

9:00 In der Übung treffen Sie diese Entscheidung selbst — und, was wichtiger ist, schreiben die Begründung auf. Die Ausgangslage ist bewusst konkret: Je Vorgang sind bis zu zwanzig Entscheidungen zu erwarten, gelesen wird immer nach Vorgang, gesucht wird nicht. Und die Entscheidungen müssen die Deinstallation nicht überdauern. Lesen Sie diese drei Sätze noch einmal — sie beantworten die Speicherfrage bereits vollständig.

9:26 Genau so sollten solche Anforderungen aussehen: nicht „wir brauchen eine Datenbank", sondern Menge, Zugriffsmuster und Lebensdauer. Wer diese drei Angaben hat, muss nicht mehr raten. Das Erfolgskriterium verlangt zwei Dinge. Erstens eine Notiz, die die Wahl gegen die beiden Alternativen begründet — wieder die Regel vom ersten Tag: Eine Begründung ohne verworfene Optionen ist keine.

9:49 Zweitens der praktische Nachweis, dass ein zweimal abgesendetes Formular nur einen Eintrag erzeugt. Probieren Sie das wirklich aus, mit zwei schnellen Klicks. Wer früh fertig ist, ergänzt das Löschen samt Rückfrage — und merkt dabei, dass Löschen im Schließfach einfacher ist, als es sich anfühlt. Der Ablauf ist die Kurzfassung des ganzen Nachmittags: Abfragen aufschreiben, Speicher wählen und begründen, Schlüsselschema festlegen, gegen Doppelanlage absichern, ausprobieren.

10:17 Schritt vier verdient eine Anmerkung: Die Kennung für einen neuen Eintrag erzeugen Sie im Resolver, nicht im Frontend. Sonst hätten Sie die Vertrauensgrenze von heute Vormittag gleich wieder aufgeweicht. Und Schritt fünf ist die Probe aufs Exempel — klicken Sie absichtlich zu schnell. Drei Punkte zum Mitnehmen, und sie fassen den Tag zusammen. Die Begründung nennt die Wahl, aber nicht die Alternativen. Der Schlüssel enthält den Titel und bricht beim Bearbeiten.

10:44 Und die Kennung entsteht im Frontend, ist damit beeinflussbar und verschiebt eine Entscheidung wieder vor die Vertrauensgrenze. Genau dort setzen wir morgen an: Der vierte Tag gehört der Sicherheit — Berechtigungen, Kontexte, ausgehende Verbindungen und die Frage, was eigentlich in Protokollen stehen darf.