Datenbanken weitergedacht – Erkenntnisse aus unserem Hackathon

Wie jeden Monat traf sich unser Entwicklerteam letzte Woche, um einen Tag lang gemeinsam ein neues Thema zu erlernen. Dieses Mal knüpften wir an unser letztes Hackathon Thema an: Datenbanken. Die Agenda ist sehr einfach:

1. Jeder wählt ein interessantes Thema
2. Wir haben 1h Zeit, um einen Überblick vorzubereiten
3. Am Ende stellt jeder vor, was er herausgefunden hat

Folgendes haben wir gelernt:

SQL Injection

SQL Injection ist ein bekanntes Thema, mit dem sich jeder Entwickler einmal beschäftigt haben sollte – besonders dann, wenn Syntactic Sugar wichtige Sicherheitsmechanismen verdeckt. Ein Beispiel in JavaScript:

query(`select * from users where users.id = ${id}`)
// vs.
query`select * from users where users.id = ${id}`

Die erste Zeile setzt den Wert direkt ein und ist dadurch anfällig für SQL Injection. Die zweite Zeile hingegen kann sich zum Beispiel mithilfe von tagged template literals in query("select * from users where users.id = ?", [id]) umwandeln. Der Unterschied ist klein, die Auswirkungen jedoch enorm.

Triggers und Scheduler

Die meisten Datenbanken bieten Möglichkeiten, auf Ereignisse zu reagieren oder wiederkehrende Abläufe zu planen.

Zuerst haben wir uns angeschaut, wie Triggers funktionieren. So lässt sich zum Beispiel ein Trigger erstellen, der bei jeder Änderung einer Zeile automatisch ein „modified_at“-Datum aktualisiert.

Anschließend haben wir untersucht, wie manche Datenbanken Schedules handhaben. Es ist beispielsweise möglich, eine Abfrage eine Stunde zeitversetzt auszuführen oder jeden Sonntag um 6 Uhr morgens eine Procedure laufen zu lassen. Besonders MySQL stellt hier viele Funktionen zur Verfügung.

Query Plans

SQL-Abfragen sind nicht immer optimal formuliert. Gleichzeitig ist es oft schwierig, eine langsame Query zu optimieren.

Ein guter Ausgangspunkt ist der sogenannte Query Plan. Darin zeigt die Datenbank, wie sie eine Query ausführen würde und in welcher Reihenfolge die einzelnen Schritte ablaufen. Zusätzlich kann man hier sowohl geschätzte Kosten als auch reale Laufzeiten einzelner Schritte ablesen.

So lassen sich Probleme in langsamen Queries besser erkennen. Manche Datenbanken geben auch direkte Hinweise zur Optimierung. Ein fehlender Index an der richtigen Stelle kann hier oft Wunder bewirken.

Und vieles mehr

Wir haben uns außerdem angeschaut, wie JOINs funktionieren, uns mit Cascade-Regeln beschäftigt, Meta-Tabellen untersucht und Strategien für Backup und Wiederherstellung diskutiert.

Insgesamt konnten wir unser Wissen vertiefen, und jeder hat mindestens einen neuen Aspekt von Datenbanken kennengelernt. Es gab wie immer auch viele technische Diskussionen, aus denen sich weitere Einsichten ergaben.

Das Verständnis für grundlegende Zusammenhänge ist uns wichtig. Es hat uns in der Vergangenheit oft geholfen, Fehler beim Debugging besser nachvollziehen zu können und so jede Menge Zeit und Kopfschmerzen gespart.