Aufgabe 21 - Umzug von SQLite nach PostgreSQL

Aufgabe 21 - Umzug von SQLite nach PostgreSQL

Worum geht es?

Sie bringen Ihr Projekt von einer Datei auf einen Datenbankdienst und richten dabei die Rechte so ein, dass ein Fehler in der Anwendung Zeilen kostet und keine Tabellen (siehe Kapitel Datenbank produktionsnah). Danach erzeugen Sie Beispieldaten in einer Menge, in der die Probleme der nächsten Aufgaben überhaupt sichtbar werden.

Was Sie dafür brauchen

• Kapitel Datenbank produktionsnah, Abschnitte Von SQLite zu PostgreSQL bis Migrationen.
• Den PostgreSQL-Dienst aus Ihrer Compose-Datei aus Aufgabe 10.
• Ihr Projekt mit Prisma oder dem ORM Ihrer Klasse.

Welche Kompetenzen Sie erwerben und zeigen

• Sie betreiben PostgreSQL als Dienst und binden die Anwendung mit einer Rolle ohne Schemarechte an.
• Sie bauen eine Zugriffsschicht, in der Datenbankabfragen an einer Stelle je Ressource liegen.
• Sie erzeugen Seed-Daten in realistischer Menge.

Pädagogische Einordnung

• Reproduktion: die Unterschiede beider Systeme benennen und die Verbindung herstellen (Teil A).
• Reorganisation und Transfer: Rollen einrichten und die Zugriffsschicht aufbauen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: die strengere Typprüfung ausloten und Seed-Daten dimensionieren (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Verbinden

1. Übertragen Sie die Vergleichstabelle aus dem Kapitel in Ihre Unterlagen. Ergänzen Sie eine dritte Spalte mit der Überschrift betrifft mein Projekt wie? und füllen Sie sie für alle sechs Zeilen aus.

2. Starten Sie den Datenbankdienst aus Ihrer Compose-Datei und verbinden Sie sich mit psql. Notieren Sie den Befehl. Denken Sie daran, dass der Port nicht veröffentlicht ist: Sie arbeiten über docker compose exec oder den SSH-Tunnel aus Aufgabe 10.

3. Setzen Sie drei Befehle ab und notieren Sie die Ausgaben: \l für die Datenbanken, \dt für die Tabellen, SELECT version();.

4. Stellen Sie die Verbindungszeichenfolge Ihres Projekts auf PostgreSQL um. Die Zeichenfolge kommt aus der Umgebung, nicht aus dem Code. Notieren Sie den Namen der Variable.

5. Lassen Sie Ihr ORM das Schema anlegen und prüfen Sie mit \dt, dass die Tabellen da sind.

Teil B - Rechte und Zugriffsschicht

1. Legen Sie zwei Rollen an, app und migrator, mit den Rechten aus dem Kapitel. Die Passwörter kommen aus der Umgebung.

2. Stellen Sie die Anwendung auf die Rolle app um. Der Migrationsschritt im Deployment benutzt migrator.

3. Weisen Sie die Trennung nach. Versuchen Sie, als app eine Tabelle anzulegen und eine zu löschen. Notieren Sie beide Fehlermeldungen.

4. Beschreiben Sie in drei bis vier Sätzen, welchen Unterschied diese Trennung im Schadensfall macht. Gehen Sie von einer Anwendung aus, in der ein Angreifer beliebiges SQL ausführen kann.

5. Sehen Sie Ihr Projekt durch und zählen Sie, an wie vielen Stellen eine Datenbankabfrage steht. Notieren Sie die Zahl.

6. Bauen Sie die Zugriffsschicht nach dem Muster im Kapitel: Route Handler, Dienstschicht, Repository, Datenbank. Verschieben Sie die Abfragen so, dass pro Ressource genau eine Datei sie enthält. Zählen Sie danach erneut und notieren Sie die neue Zahl.

7. Beantworten Sie in zwei bis drei Sätzen, welche Arbeit diese Aufteilung Ihnen in den Aufgaben 23 und 24 erspart.

Teil C - Strenge Typen und realistische Daten

1. PostgreSQL ist streng, wo SQLite nachgiebig war. Versuchen Sie, in eine Zahlenspalte Text einzufügen, in eine Spalte mit NOT NULL einen leeren Wert, und in ein Datumsfeld eine Zeichenkette im Format 12.03.2026. Notieren Sie alle drei Fehlermeldungen.

2. Beschreiben Sie in drei bis vier Sätzen, warum diese Strenge ein Vorteil ist, obwohl sie beim Umzug Arbeit macht. Nennen Sie einen Fall, in dem ein nachgiebiges System den Fehler erst Wochen später sichtbar macht.

3. Schreiben Sie ein Seed-Skript, das eine leere Datenbank füllt. Die Menge orientiert sich an Ihrer Schätzung aus Aufgabe 03: Wenn Sie dort mit einigen tausend Datensätzen gerechnet haben, erzeugt Ihr Skript einige tausend.

4. Achten Sie darauf, dass die Daten in ihrer Verteilung realistisch sind. Wenn eine Maschine in der Wirklichkeit hundert Buchungen hat und eine andere zwei, dann bilden Sie das ab. Gleichverteilte Testdaten verstecken genau die Probleme, die Sie in Aufgabe 23 suchen werden.

5. Führen Sie das Skript aus und prüfen Sie die Menge mit SELECT count(*) je Tabelle. Notieren Sie die Zahlen.

6. Laden Sie eine Übersichtsseite Ihres Projekts einmal mit zehn Datensätzen und einmal mit dem vollen Seed. Messen Sie beide Ladezeiten und notieren Sie sie. Diese beiden Zahlen sind Ihr Ausgangswert für Aufgabe 23.

7. Legen Sie die Rollen, die Verbindungszeichenfolge ohne Passwort und den Seed-Umfang als Abschnitt Datenbank in docs/architektur.md ab.

Wissenscheck

1. Nennen Sie drei Fragen, die bei SQLite gar nicht auftreten und bei einem Datenbankdienst schon.
2. Warum verbindet sich die Anwendung nicht als Superuser?
3. Wozu dient die zweite Rolle für Migrationen?
4. Welche Frage beantwortet die Zugriffsschicht, und warum ist die Antwort wichtig?
5. Was leistet ein ORM, und was verdeckt es?
6. Warum sind realistische Seed-Daten mehr als Bequemlichkeit?
7. Warum verstecken gleichverteilte Testdaten Leistungsprobleme?

Abgabe

Das Projekt läuft gegen PostgreSQL, die Anwendung verbindet sich als app ohne Schemarechte. Das Seed-Skript liegt im Repository. In docs/architektur.md steht der Abschnitt Datenbank. In protokoll.md stehen die ausgefüllte Vergleichstabelle, die beiden Fehlermeldungen aus Teil B Punkt 3, die drei aus Teil C Punkt 1, die Zahl der Abfragestellen vorher und nachher sowie die beiden Ladezeiten.