Dateizugriff, Datenaustausch und Datenbanken

JavaScript — Dateien, Daten und Datenbanken

0:00 Im siebten Modul haben wir es angekündigt, jetzt lösen wir es ein: Was nur im Speicher lebt, ist mit dem Programmende weg. In diesem Modul bekommen unsere Daten einen Ort. Wir schreiben sie in Dateien, tauschen sie mit anderen Systemen aus und legen sie in einer Datenbank ab. Dabei begegnet uns der wichtigste Sicherheitsinhalt des gesamten Kurses — eine Regel, die Sie nie brechen sollten.

0:23 Und am Ende führen wir alles zusammen: Das letzte Kapitel ist die Integration, in der sich jedes vorherige Modul auszahlt.

Daten dauerhaft machen

0:31 Vier Kapitel. Zuerst Dateien — der einfachste dauerhafte Speicher, mit einem Detail zum Pfadaufbau, das häufiger Ärger macht, als man denkt. Dann der Datenaustausch, wo Umwandeln und Prüfen als zwei getrennte Schritte behandelt werden. Danach die relationale Datenbank, und dort kommt die erwähnte Sicherheitsregel. Und zum Schluss die Integration: ein kleines Projekt aus mehreren Modulen mit klaren Grenzen — und einer Probe, die zeigt, ob die Grenzen richtig gezogen sind.

Dateien lesen und schreiben

1:00 Beginnen wir mit der einfachsten Form von Dauerhaftigkeit. Technisch kennen wir das schon aus Modul dreizehn — hier geht es um die Organisation. Und um den Pfadaufbau, den wir bewusst nicht überspringen, weil relative Pfade eine sehr häufige Fehlerquelle sind. Der Ablauf ist ein Kreis: Text lesen, in Objekte wandeln, damit arbeiten, den geänderten Stand zurückschreiben. Vier Stationen, und jede haben wir einzeln behandelt.

1:25 Die Datei ist dabei der einfachste dauerhafte Speicher — kein Server, keine Installation, kein Betrieb. Für viele kleine Werkzeuge ist das völlig ausreichend, und man sollte den Schritt zur Datenbank nicht früher machen als nötig. Wichtig ist nur, dass dieser Kreis vollständig durchlaufen wird. Wer nur schreibt, ohne vorher zu lesen, überschreibt den vorhandenen Bestand — der häufigste Fehler dieses Kapitels.

1:50 Zwei kurze Funktionen, und die Beschriftung nennt das Entwurfsprinzip: Das hier ist die einzige Stelle im Projekt mit Dateizugriff. Alles andere geht über diese beiden Funktionen. Warum das lohnt, sehen wir im letzten Kapitel. Ein Detail zum Schreiben: Die Zwei im letzten Argument ist die Einrückungstiefe. Für Dateien ist das sinnvoll — die Datei bleibt lesbar, und Änderungen sind in der Versionsverwaltung nachvollziehbar.

2:16 Für den Netzwerkweg wäre es unnötiger Ballast, weil dort niemand hineinschaut und jedes Byte zählt. Kleine Entscheidung, spürbarer Unterschied. Das ist der angekündigte Teil, den man nicht überspringen sollte. Der Kern steht im Fußtext: Ein fest verdrahteter relativer Pfad hängt davon ab, aus welchem Verzeichnis der Befehl gestartet wurde.

2:36 Ihr Programm funktioniert also, solange Sie im Projektordner stehen, und scheitert, sobald jemand es von woanders aufruft — etwa aus einem Startskript oder einem Zeitplaner. Die Lösung im Code baut den Pfad relativ zur Moduldatei auf, nicht relativ zum Arbeitsverzeichnis. Damit ist er unabhängig davon, wo der Befehl abgesetzt wurde.

2:55 Das ist eine dieser Kleinigkeiten, die den Unterschied zwischen Skript und Werkzeug ausmachen. Führen Sie den vollen Kreis durch: Ein neuer Eintrag steht nach dem Lauf in der Datei, und die vorhandenen sind unverändert. Beide Bedingungen zusammen sind der Prüfstein. Und dann die dritte, die auf das vorige Beispiel zielt: Der Aufruf muss auch aus einem anderen Arbeitsverzeichnis heraus funktionieren.

3:19 Probieren Sie es wirklich aus, wechseln Sie einmal das Verzeichnis. Der Hinweis nennt den strukturellen Rat, der den Rest des Moduls trägt: Bündeln Sie alle Dateizugriffe in einem Modul. Dann ist ein späterer Wechsel der Speicherart eine lokale Änderung statt einer Operation am offenen Herzen. Den Bestand zu überschreiben, statt ihn zu lesen und zu ergänzen, ist der Fehler mit dem größten Schadenspotenzial — und er fällt oft erst auf, wenn die alten Daten schon weg sind.

3:46 Relative Pfade sind der Fall aus dem Codebeispiel; sie funktionieren in der Entwicklung und brechen im Betrieb. Die fehlende Kodierungsangabe kennen wir aus Modul dreizehn: Sie bekommen rohe Bytes statt Text. Und der vierte Punkt ist die strukturelle Warnung: Dateizugriffe über das ganze Projekt zu verstreuen, macht jeden späteren Wechsel zu einer Suchaktion.

Datenaustausch mit JSON und Schnittstellen

4:06 Jetzt der Austausch mit anderen Systemen. Ein Kernsatz trägt dieses Kapitel, und er klingt schärfer, als er gemeint ist: Herkunft von einer Schnittstelle ist kein Qualitätsmerkmal. Wer das verinnerlicht hat, schreibt robustere Software. Datenaustausch heißt, Objekte in ein übertragbares Format zu bringen und wieder zurück. JSON ist dafür der Standard — das kennen wir seit Modul drei.

4:29 Der entscheidende Zusatz steht am Ende: Jede Rückumwandlung braucht eine Prüfung, ob die Daten die erwartete Form haben. Das ist keine Paranoia, sondern die Konsequenz aus einer einfachen Beobachtung: Die Umwandlung prüft nur die Syntax, nicht den Sinn. Ein gültiges JSON kann ein leeres Objekt sein, eine Zahl, eine Liste von Dingen, mit denen Sie nichts anfangen können. Die Umwandlung ist trotzdem gelungen.

4:54 Drei Ebenen der Prüfung in wenigen Zeilen. Zuerst die Umwandlung, die scheitern kann. Dann die Prüfung des äußeren Typs: Ist das überhaupt eine Liste? Und dann die Einzelprüfung: Hat jeder Eintrag die Pflichtfelder? Diese Reihenfolge ist kein Zufall — von grob nach fein, wie beim Trichter aus dem Eingabemodul. Der Fußtext wiederholt den Kern: Die Umwandlung gelingt auch bei fachlich unbrauchbarem Inhalt. Sie prüft Klammern und Anführungszeichen, mehr nicht.

5:23 Alles Weitere ist Ihre Aufgabe, und dieser Code zeigt, wie überschaubar sie ist. Vier Gründe, alle aus der Praxis. Schnittstellen ändern ihre Antwortform, ohne zu fragen — ein Feld wird optional, ein Typ ändert sich, und Ihr Code bricht an einer Stelle, die Sie seit Monaten nicht angefasst haben. Dateien werden von Hand bearbeitet und dabei beschädigt; ein fehlendes Komma genügt. Nutzereingaben sind grundsätzlich ungeprüft, das ist unser Dauerthema.

5:50 Und der vierte Punkt fasst zusammen, worum es geht: Eine gelungene Umwandlung sagt nichts über die Brauchbarkeit der Daten. Diese Trennung zwischen syntaktisch gültig und fachlich brauchbar ist der Kern des Kapitels. Erzeugen Sie drei getrennte Meldungen: für ungültiges JSON, für eine unerwartete Struktur und für einen Eintrag mit fehlendem Pflichtfeld.

6:12 Drei verschiedene Ursachen, drei verschiedene Auskünfte — und drei verschiedene Reaktionen, die daraus folgen können. Der Hinweis nennt die Reihenfolge, die sich bewährt hat: erst der äußere Typ, dann die einzelnen Einträge. Andersherum prüfen Sie Einträge in etwas, das gar keine Liste ist, und bekommen eine Fehlermeldung, die vom eigentlichen Problem ablenkt.

6:33 Daten zu vertrauen, weil sie von einer Schnittstelle stammen, ist der Kernfehler dieses Kapitels — eine Schnittstelle ist ein Absender, kein Gütesiegel. Nur den äußeren Typ zu prüfen und die Einträge auszulassen, ist die halbe Arbeit: Sie wissen dann, dass eine Liste angekommen ist, aber nicht, ob etwas Brauchbares darin steht.

6:52 Der dritte Punkt ist eine Entwurfsfrage: Prüfung und Fachlogik zu vermischen, macht beides schwerer testbar. Und der vierte ist heikel: Bei einem Fehler die halb geprüften Daten trotzdem weiterzureichen, verlagert das Problem nur nach hinten.

Arbeiten mit einer relationalen Datenbank

7:06 Und jetzt der wichtigste Sicherheitsinhalt des gesamten Kurses. Es geht um eine einzige Regel, sie ist in einem Satz gesagt, und sie wird trotzdem seit Jahrzehnten gebrochen — mit Folgen, die regelmäßig in den Nachrichten landen. Eine relationale Datenbank speichert Daten in Tabellen aus Zeilen und Spalten und wird über eine eigene Abfragesprache angesprochen.

7:27 Für unsere Zwecke nehmen wir SQLite: Es hält den gesamten Bestand in einer lokalen Datei, braucht keinen Server und keine Installation. Ideal, um das Prinzip zu lernen — und ausdrücklich nicht nur zum Lernen. SQLite steckt in unzähligen Anwendungen, in jedem Smartphone, in vielen Desktop-Programmen. Die Konzepte, die Sie hier üben, gelten für die großen Systeme genauso: dieselbe Abfragesprache, dieselben Sicherheitsregeln.

7:53 Hier ist die Regel, und der Kontrast könnte deutlicher nicht sein. Oben die sichere Form: Die Abfrage enthält einen Platzhalter, das Fragezeichen, und der Wert wird getrennt übergeben. Die Datenbank weiß dann genau: Das ist ein Wert, kein Befehl. Unten die unsichere Form, auskommentiert — eine Zeichenkette, in die eine Eingabe hineingeklebt wird. Was passiert, wenn diese Eingabe selbst Anführungszeichen und Befehle enthält?

8:19 Dann verändert sie die Abfrage. Das ist SQL-Injection, und damit lassen sich Daten auslesen, verändern oder löschen. Kein Sonderfall — einer der häufigsten Angriffe überhaupt. Neben der Sicherheit gibt es ein praktisches Thema: Datenbank und JavaScript haben verschiedene Gewohnheiten. Spaltennamen mit Unterstrichen treffen auf Eigenschaften in Binnengroßschreibung. Wahrheitswerte gibt es in SQLite gar nicht — dort stehen Null und Eins.

8:47 Und Zeilen sind keine Objekte. Diese Übersetzung muss also irgendwo stattfinden. Der Fußtext sagt, wo: an genau einer Stelle. Sonst zieht sie sich durch das ganze Projekt, und Sie finden im Formatierungscode plötzlich eine Prüfung auf die Zahl Eins — mit einem Kommentar, den niemand mehr versteht. Nutzen Sie Platzhalter — und dann der Test, der es beweist: Eine Eingabe mit einem Anführungszeichen darin muss zu einem leeren Ergebnis führen, nicht zu einem Fehler und schon gar nicht zu einer veränderten Abfrage.

9:18 Das Anführungszeichen wird dann nämlich als das behandelt, was es ist: ein Zeichen in einem Suchbegriff. Der Hinweis stellt eine wichtige Klarstellung: Prüfung der Eingabe und parametrisierte Abfrage ergänzen einander — eines ersetzt das andere nicht. Wer nur prüft, verlässt sich darauf, an alles gedacht zu haben. Das tut man nie.

9:38 Der erste Punkt ist die Regel in Verbotsform, und der Zusatz ist ernst gemeint: auch nur ein einziges Mal. Genau diese eine Stelle, an der es mal schnell gehen musste, ist die Lücke. Der zweite Punkt ist die falsche Sicherheit aus der Aufgabe — Eingabeprüfung allein reicht nicht. Der dritte ist der Alltagsärger: Wahrheitswerte aus SQLite kommen als Null und Eins, und Null ist unwahr — was hier ausnahmsweise sogar passt, aber die Eins ist eben nicht dasselbe wie ein echtes Ja.

10:04 Und der vierte betrifft die Schreibweise: Spaltennamen unverändert als Objekteigenschaften zu übernehmen, trägt die Datenbankkonventionen ins ganze Programm.

Alles zusammenführen

10:14 Zum Abschluss die Integration. Hier zahlt sich jedes vorherige Modul aus — Funktionen, Module, Fehlerbehandlung, Prüfung, Datenzugriff. Und am Ende steht eine Probe, die zeigt, ob die Struktur wirklich trägt oder nur ordentlich aussieht. Vier Prinzipien in einem Satz. Eine Zuständigkeit je Modul — das kennen wir aus Modul vierzehn. Datenzugriff getrennt von Fachlogik.

10:37 Formatierung ohne Wissen über die Herkunft der Daten. Und ein Einstiegspunkt, der nur verdrahtet. Besonders das dritte Prinzip lohnt einen zweiten Blick: Die Formatierung soll nicht wissen, ob die Daten aus einer Datei, einer Datenbank oder einer Schnittstelle stammen. Sie bekommt Objekte und macht daraus Text. Wenn sie mehr weiß, ist sie an die Herkunft gefesselt — und ein Wechsel der Datenquelle zieht plötzlich Änderungen an der Darstellung nach sich.

11:05 Fünf Module, und jedes lässt sich in einem Satz erklären — das ist das Kriterium aus Modul vierzehn. Die einzige Stelle mit Dateizugriff. Die Prüfung, die Fehler zurückliefert statt sie selbst zu behandeln. Die Darstellung, unabhängig von der Herkunft. Die Fachlogik mit Filtern und Gruppieren. Und der Einstiegspunkt, der koordiniert. Der Fußtext nennt ein Detail mit Bedeutung: Der Datenordner liegt bewusst neben dem Quellordner, nicht darin.

11:32 Damit ist der Bestand austauschbar, ohne Code anzufassen — und man kann Daten und Programm getrennt versionieren und sichern. Fünf Schritte, und lesen Sie sie als Fließband: einlesen, prüfen, filtern, gruppieren, ausgeben. Jeder Schritt bekommt, was der vorige liefert. Und jeder Schritt gehört einem anderen Modul — das ist der Punkt.

11:54 Der Fußtext nennt die Auflage, die den Einstiegspunkt schlank hält: Er enthält selbst keine Fachlogik, er ruft nur auf. Wenn Sie dort eine Bedingung schreiben oder eine Zeichenkette zusammenbauen, ist das ein Warnsignal. Diese Arbeit gehört in eines der Module — und dort ist sie testbar, wiederverwendbar und benannt. Das ist die angekündigte Probe, und sie ist elegant: Wechseln Sie von Datei auf Datenbank — und prüfen Sie, was sich dabei ändern muss.

12:22 Wenn Ihre Grenzen stimmen, ist nur das Zugriffsmodul betroffen. Prüfung, Fachlogik und Formatierung bleiben unverändert. Der Hinweis nennt das Diagnosekriterium, das ich Ihnen mitgeben möchte: Muss die Formatierung angepasst werden, war die Grenze an der falschen Stelle. Das ist eine Erkenntnis, die man nur durch den Versuch bekommt. Struktur beurteilt man nicht am Aussehen, sondern daran, wie sie sich bei einer Änderung verhält.

12:48 Fachlogik in den Einstiegspunkt zu schreiben, ist die häufigste Erosion — sie beginnt mit einer kleinen Bedingung und endet mit dreihundert Zeilen. Die Formatierung wissen zu lassen, woher die Daten kommen, ist der Fehler aus der Probe: Er zeigt sich erst, wenn man tatsächlich wechseln will. Dateizugriffe an mehreren Stellen zu verteilen, macht dasselbe mit dem Zugriffsmodul.

13:08 Und der vierte Punkt betrifft die Testbarkeit: Prüfung und Fachlogik in derselben Funktion zu vermengen, bedeutet, dass Sie beides nur zusammen prüfen können — und bei einem Fehlschlag nicht wissen, welche der beiden schuld ist.

Die Daten haben einen Ort

13:21 Drei Sätze zum Mitnehmen, und einer davon ist eine Regel ohne Ausnahme. Erstens: Dateizugriffe gehören an genau eine Stelle im Projekt — dann ist ein Wechsel der Speicherart eine lokale Änderung. Zweitens: Umwandeln und Prüfen sind zwei Schritte, und jeder kann für sich scheitern; eine gelungene Umwandlung sagt nichts über die Brauchbarkeit.

13:40 Und drittens die Regel, die Sie nie brechen sollten: SQL niemals aus Zeichenketten zusammensetzen, immer Platzhalter verwenden. Im letzten Modul geht es um das, was aus gutem Code guten Code macht — sauber schreiben und fremden Code lesen.