Datenbanken, Dateien und interne Datenhaltung

Datenbanken, Dateien und interne Datenhaltung

0:00 Eine Datenbank ist keine Tabellenkalkulation mit Netzwerkanschluss. Das klingt nach einer Selbstverständlichkeit, und trotzdem sieht man in Automatisierungsprojekten regelmäßig Workflows, die genau so mit ihr umgehen: zeilenweise lesen, zeilenweise schreiben, keine Transaktion, keine Parameter. Solange nur eine Person testet, funktioniert das. Beim ersten Parallellauf nicht mehr.

0:22 In diesem Modul geht es um die drei Orte, an denen Daten in einem Workflow liegen — die Fachdatenbank, die Datei und die interne Ablage — und um die Regeln, die für jeden davon gelten.

Datenbanken, Dateien und interne Datenhaltung

0:33 Wir bleiben am zweiten Tag. Zuerst der Zugriff auf relationale Datenbanken und die Frage, was eine Transaktion in einem Workflow eigentlich bedeutet. Dann Dateien: PDF, CSV, Office — wie kommen die fachlichen Daten heraus, und wie bleibt die Sache beherrschbar? Danach die Data Tables, die wir gerade schon gestreift haben, diesmal im Detail.

0:54 Und zum Schluss ein Thema, das man gern verschiebt und das später teuer wird: Aufbewahrung und Löschen.

Relationale Datenbanken in n8n

1:01 Fangen wir bei der Datenbank an. n8n bringt Bausteine für die verbreiteten Systeme mit — und das Angenehme daran ist zugleich das Gefährliche: Es sieht so einfach aus, dass man vergisst, dass die Regeln der Datenbank weiter gelten. Die Datenbank-Bausteine führen Abfragen und Änderungen aus und geben die Ergebniszeilen als Items zurück.

1:22 Damit fügt sich die Datenbank nahtlos in das Datenmodell ein, das wir in Modul drei besprochen haben. Der Satz, auf den es ankommt, steht am Ende: Die Regeln der Datenbank gelten unverändert — der Workflow ist nur ein weiterer Aufrufer. Für die Datenbank sieht n8n aus wie jede andere Anwendung. Sie bekommt keine Sonderrechte, keine Nachsicht bei schlechten Abfragen und keine Absolution für fehlende Indizes.

1:46 Wer das im Kopf behält, trifft hier automatisch bessere Entscheidungen. Vier Punkte, und der zweite ist der, den man unterschätzt. Erstens: Parameter gehören als Parameter übergeben, nicht in die Abfrage hineingeschrieben — dazu gleich mehr. Zweitens, und das ist die Fließband-Regel in ihrer teuersten Form: Ein Baustein verarbeitet jedes Item einzeln, aus zweihundert Items werden also zweihundert Abfragen.

2:11 Drittens: Eine Transaktion endet mit dem Aufruf; sie spannt sich nicht über mehrere Bausteine. Das ist eine Erwartung, die viele mitbringen und die hier nicht trägt. Und viertens folgt daraus: Was der Workflow nicht in einem Schritt schafft, braucht einen Ausgleichsschritt — das Muster von vorhin. Fünf Schritte, die man sich zur Gewohnheit machen sollte. Schreiben Sie die Abfrage mit Platzhaltern und binden Sie die Werte als Parameter.

2:37 Prüfen Sie, ob viele Items besser eine Sammelabfrage ergeben — das ist oft der Unterschied zwischen zwei Sekunden und zwei Minuten. Benennen Sie die Konsistenzgrenze: Was muss zusammen gelten? Klären Sie, ob ein zweiter Lauf harmlos ist; die Tabelle aus Modul fünf hilft dabei. Und halten Sie das Ergebnis gegen die erwartete Zeilenzahl.

2:57 Ein Hinweis zum Schluss: Wo kein Ausgleichsschritt möglich ist, gehört die Wirkung ans Ende des Vorgangs — dann ist wenigstens alles andere schon sicher. Der erste Punkt ist eine der ältesten Sicherheitslücken überhaupt, in neuem Gewand: Werte werden per Expression in den SQL-Text eingesetzt. Das ist eine Einladung zur Einschleusung — und es fällt nicht auf, weil es mit sauberen Testdaten funktioniert.

3:22 Übrigens meldet genau das die eingebaute Sicherheitsprüfung von n8n; wir sehen sie am fünften Tag. Der zweite: Für jedes Item eine eigene Abfrage, obwohl eine Sammelabfrage genügt. Der dritte: Zwei Schreibschritte werden als Transaktion gedacht, sind aber zwei Vorgänge. Und der vierte fällt erst nachts auf: Fehlende Indizes, wenn der Abgleich plötzlich Stunden braucht.

Dateien und Binärdaten verarbeiten

3:45 Jetzt zu den Dateien. In der Praxis kommen erstaunlich viele Geschäftsvorgänge immer noch als Anhang an — und das wird sich so schnell nicht ändern. Gut, dass n8n dafür eigene Bausteine mitbringt. Diese Bausteine sortieren sich nach Richtung. Extract From File holt aus einem Binärformat die fachlichen Daten heraus — aus der PDF werden JSON-Felder.

4:07 Convert to File macht den umgekehrten Weg, aus Daten wird eine Datei. Read/Write Files from Disk liest und schreibt auf der Maschine, auf der n8n läuft; merken Sie sich diesen, wir kommen am fünften Tag darauf zurück, denn er ist einer der Bausteine, die man aus Sicherheitsgründen häufig sperrt. HTML und XML überführen Auszeichnungssprachen in Daten. Und Compression packt und entpackt Archive. Für lokale Dateien gibt es zusätzlich einen Trigger, der bei Änderungen auslöst.

4:36 Vier Unterschiede, die alle aus der Struktur von Modul drei folgen. Binärdaten stehen unter dem Schlüssel binary, nicht unter json — das ist die Trennung, die wir gesehen haben. Sie tragen Base64-kodierte Daten sowie MIME-Typ, Endung und Dateinamen. Und jetzt der praktische Teil: Transformations-Bausteine für json lassen sie unberührt oder verlieren sie.

4:57 Das ist die häufigste Ursache dafür, dass ein Anhang unterwegs verschwindet. Und viertens wirkt ihre Größe unmittelbar auf Speicherbedarf und Laufzeit — bei Nutzdaten reden wir über Kilobyte, bei Anhängen über Megabyte. Fünf Schritte, und der erste kommt vor allem anderen: Prüfen Sie, ob Typ und Größe überhaupt erwartet werden. Nicht nachdem Sie die Datei geöffnet haben — davor.

5:21 Extrahieren Sie dann die fachlichen Daten und prüfen Sie diese gegen das erwartete Schema. Legen Sie die Datei früh ab und reichen Sie nur noch die Kennung weiter; das ist der Trick, mit dem Sie den Speicherverbrauch im Griff behalten. Und legen Sie fest, wann Datei und Ausführungsdaten gelöscht werden. Selbst gehostet steuern übrigens eigene Umgebungsvariablen, wo und wie Dateien überhaupt liegen — dazu am sechsten Tag mehr.

5:46 Der erste Punkt ist der Speicherfresser: Die Datei wird durch zehn Bausteine gereicht und liegt zehnmal im Speicher. Dagegen hilft Schritt vier von eben. Der zweite ist ein Sicherheitsproblem: Es wird auf die Dateiendung vertraut statt auf den tatsächlichen Inhalt — eine umbenannte Datei ist keine andere Datei. Der dritte betrifft die Instanz: Lesen und Schreiben auf der Maschine bleibt erlaubt, obwohl es kein Workflow braucht.

6:09 Und der vierte ist eine Betriebsfrage: Ein Anhang mit vierzig Megabyte bringt den Lauf zum Erliegen, weil niemand die Größe prüft — genau das, was Schritt eins verhindert.

Data Tables als interne Ablage

6:20 Wir hatten die Data Tables im letzten Modul schon kurz. Jetzt sehen wir sie uns genauer an — vor allem die drei Wege, auf denen man sie benutzt, und die eine Möglichkeit, die es ausdrücklich nicht gibt. Data Tables halten tabellarische Daten innerhalb der Projektgrenzen. Die Anwendungsfälle aus der Dokumentation sind: Stände über mehrere Workflows eines Projekts halten, Marker gegen Doppelläufe setzen, Nachschlagetabellen führen und Auswertungsdaten für KI-Workflows ablegen.

6:48 Den letzten Punkt merken Sie sich für Tag fünf — die Evaluationsdatensätze, mit denen wir dort KI-Qualität messen, liegen genau hier. Was diese vier Zwecke eint: Es sind Hilfsdaten für den Betrieb der Automatisierung, keine Geschäftsdaten. Diese Unterscheidung trägt durch das ganze Thema. Drei Zugänge, und der vierte Punkt ist der, den man kennen muss. Der Data-Table-Baustein liest und schreibt aus dem Workflow heraus — der Normalfall.

7:14 Der Reiter Data tables in der Oberfläche erlaubt Ansehen und Bearbeiten ohne Workflow, was beim Aufräumen und beim Anlegen von Testdaten sehr praktisch ist. Der API-Endpunkt spricht die Tabellen programmatisch an, etwa aus einer Pipeline. Und dann der Punkt, der regelmäßig für Überraschung sorgt: Aus dem Code-Node gibt es keinen Zugriff. Das ist keine Lücke, das ist Absicht.

7:37 Wer im Code eine Tabelle braucht, muss den Baustein davorschalten. Der erste Punkt ist die Entwicklung, vor der ich schon gewarnt habe: Die Tabelle wird zur Stammdatenhaltung, ohne dass jemand sie pflegt. Der zweite ist die Zahl aus dem letzten Modul, diesmal als Betriebsrisiko: Alle Data Tables einer Instanz teilen sich 200 Mebibyte, und niemand beobachtet den Füllstand.

7:58 Der dritte ist die Folge davon — ab der Grenze schlagen Schreibzugriffe im laufenden Betrieb fehl, also mitten in einem produktiven Vorgang. Und der vierte ist die Datenschutzfrage: Im Projekt sehen alle Mitglieder die Tabelle, auch wenn der Inhalt heikel ist.

Große Datenmengen, Datenschutz und Aufbewahrung

8:13 Zum Abschluss ein Thema, das man in Projekten gern nach hinten schiebt: Was passiert eigentlich mit all den Daten, die sich ansammeln? Löschen ist ein Prozessschritt, kein Aufräumen — und diesen Unterschied macht man am besten früh. Vier Stellen, an denen es zuerst klemmt. Der Speicherbedarf eines Laufs wächst mit den Daten, die er mitführt — deshalb der Rat, Dateien früh abzulegen.

8:36 Ausführungsdaten werden gespeichert und wachsen unbemerkt mit; das ist die häufigste Ursache für eine überraschend große Datenbank. Die Ablage der Binärdaten wirkt auf die Parallelität — welche Möglichkeiten es gibt, sehen wir am sechsten Tag, und eine Kombination ist dort ausdrücklich nicht möglich. Und viertens, als Faustregel: Was in einem Lauf nicht zu schaffen ist, gehört in Portionen zerlegt. Ein Lauf, der acht Stunden dauert, ist kein Lauf, sondern ein Risiko.

9:05 Fünf Schritte, und der letzte ist der, an dem sich alles entscheidet. Benennen Sie je Datenart, wie lange sie gebraucht wird — das ist eine fachliche Frage, oft sogar eine juristische. Setzen Sie die Workflow-Einstellungen zum Speichern der Ausführungsdaten entsprechend. Nehmen Sie sensible Inhalte über die Schwärzung aus.

9:24 Vereinbaren Sie Löschfristen für abgelegte Dateien und Data-Table-Zeilen. Und dann bauen Sie einen Workflow, der das Löschen tatsächlich ausführt. Ohne diesen letzten Schritt bleibt die Frist eine Absichtserklärung — und Absichtserklärungen haben vor einer Datenschutzbehörde noch nie jemanden gerettet. Der erste Punkt ist der verbreitetste Datenschutzverstoß in Automatisierungsprojekten: Ausführungsdaten enthalten personenbezogene Daten und werden unbegrenzt gespeichert.

9:51 Niemand entscheidet das — es passiert, weil die Voreinstellung so ist. Der zweite ist der fehlende fünfte Schritt: Die Löschfrist steht im Konzept, aber kein Workflow setzt sie um. Der dritte ist eine Frage der Reihenfolge: Datenminimierung wird am Ende versucht statt am Eingang — dabei ist das, was Sie gar nicht erst aufnehmen, das Einzige, was sicher nicht ausläuft.

10:12 Und der vierte: Testdaten aus der Produktion landen dauerhaft in einer Data Table.

Übung

10:18 Jetzt bauen Sie den Weg einer echten Datei — von der E-Mail bis in die Fachdatenbank. Und Sie bauen ihn so, dass er ein zweites Mal ausgeführt werden kann, ohne Schaden anzurichten. Kesselwerk erhält Wartungsnachweise als PDF-Anhang per E-Mail. Daraus sollen die Messwerte gewonnen, in der Fachdatenbank abgelegt und an Einsatzplan weitergegeben werden.

10:39 Der Verarbeitungsstand wird in einer Data Table mitgeführt — das ist genau der Marker-Anwendungsfall von vorhin. Sie sehen an diesem kleinen Beispiel alle drei Ablagen zusammenwirken: die Datei als Binärdatum, die Fachdaten in der Datenbank, der Bearbeitungsstand in der internen Tabelle. Jede an ihrem Platz. Das Lernziel: Binärdaten so verarbeiten, dass Prüfung, Auswertung und Ablage getrennte, wiederholbare Schritte sind.

11:05 Erfolgreich sind Sie, wenn eine fehlerhafte Datei abgewiesen statt verarbeitet wird, die Messwerte in der Datenbank stehen und ein zweiter Lauf mit derselben Datei keinen zweiten Datensatz erzeugt. Dieser dritte Punkt ist der anspruchsvollste — und Sie werden gleich sehen, dass die Reihenfolge darüber entscheidet. Wer früh fertig ist, ergänzt eine Löschregel für Anhänge, die älter als dreißig Tage sind. Damit haben Sie den fünften Schritt von eben tatsächlich gebaut.

11:32 Eine Stunde, fünf Schritte. Prüfen Sie Typ und Größe des Anhangs vor jeder weiteren Verarbeitung. Gewinnen Sie dann mit Extract From File die Messwerte und prüfen Sie diese gegen das Schema — zwei getrennte Prüfungen, eine technische und eine fachliche. Schreiben Sie die Werte parametrisiert in die Fachdatenbank. Halten Sie den Verarbeitungsstand in der Data Table fest.

11:53 Und spielen Sie zum Schluss dieselbe Datei erneut ein und beobachten Sie, was geschieht. Wenn dabei ein zweiter Datensatz entsteht, liegt es fast immer an der Reihenfolge der beiden letzten Schritte. Vier Fallen, und die erste ist die angekündigte: Der Doppellauf-Schutz greift erst nach dem Schreiben in die Datenbank — dann ist der zweite Datensatz schon da.

12:15 Der Marker gehört davor. Zweitens: Die PDF wird weitergereicht, obwohl nur die Messwerte gebraucht werden; das ist der Speicherfresser aus dem zweiten Kapitel. Drittens: Der Dateiname wird als Schlüssel verwendet und ist nicht eindeutig — zwei Betriebe nennen ihre Datei wartung.pdf. Und viertens: Die Data Table wächst je Lauf um eine Zeile, ohne dass etwas sie räumt. Zweihundert Mebibyte klingen nach viel, bis man rechnet.