Datenbank und Oberfläche: Wie eine Webanwendung zusammenspielt
Eine Webanwendung besteht nicht aus Masken, sondern aus Daten, Regeln und Sichten darauf. Wer diese Ebenen kennt, versteht, warum manche Wünsche klein sind und andere nur klein aussehen.
Das lernen Sie
Fünf Ebenen, die jede Angabe durchläuft
- 1MaskeDas Feld, in das jemand etwas einträgt.
- 2RegelnWas gültig ist, wer es ändern darf, was daraus folgt.
- 3TabelleDie Spalte, in der der Wert liegt, mit Typ und Pflichtangabe.
- 4BeziehungenWoran der Datensatz hängt — Kunde, Auftrag, Position.
- 5AuswertungListen, Filter, Exporte, die den Wert verwenden.
Die Oberfläche ist die letzte dieser Ebenen und die einzige, die man sieht. Deshalb wird der Aufwand eines Vorhabens dort gesucht — und dort ist er selten.
Beziehungen: woran ein Datensatz hängt
Daten werden nicht in einer großen Tabelle gehalten, sondern in mehreren, die aufeinander verweisen. Ein Auftrag verweist auf einen Kunden, eine Position auf einen Auftrag und einen Artikel.
Diese Verweise sind der Grund, warum manche Fragen einfach zu beantworten sind und andere nicht. „Alle Aufträge dieses Kunden" folgt einem vorhandenen Verweis. „Alle Kunden, die im letzten Quartal einen bestimmten Artikel gekauft haben" verlangt mehrere Schritte — machbar, aber nicht umsonst.
Sie sind auch der Grund, warum das Löschen eines Datensatzes selten einfach ist: Ein Kunde mit Aufträgen kann nicht verschwinden, ohne dass jemand entscheidet, was mit den Aufträgen geschieht.
Die Datenstruktur ist die wichtigste frühe Entscheidung
Oberflächen lassen sich umbauen. Abläufe lassen sich ändern. Eine Datenstruktur, auf der schon Jahre an Daten liegen, lässt sich nur mit Aufwand und Risiko ändern — jede Änderung muss die vorhandenen Daten mitnehmen, und eine falsch übertragene Zeile fällt oft erst Monate später auf.
Deshalb stellen wir zu Beginn Fragen, die unverhältnismäßig wirken: Kann ein Auftrag mehrere Ansprechpartner haben? Kann eine Position nachträglich die Menge ändern, und soll der alte Wert nachvollziehbar bleiben? Kann ein Kunde gleichzeitig Lieferant sein? Die Antworten kosten jetzt zehn Minuten und später Wochen.
Ein Beispiel aus der Praxis
„Nur ein Feld mehr"
Zum Auftrag soll eine Kostenstelle erfasst werden. In der Maske ist das eine Zeile. Dann beginnen die Fragen: Was passiert mit den dreitausend bestehenden Aufträgen ohne Kostenstelle — bleibt das Feld dort leer, oder ist es Pflicht? Darf jede Rolle sie ändern, auch nachträglich? Erscheint sie in der Übergabe an die Buchhaltung? Bleiben alte Auswertungen vergleichbar?
Keine dieser Fragen ist technisch. Alle müssen beantwortet sein, bevor das Feld gebaut werden kann. Deshalb fragt ein Entwickler nach dem Bestand, der Übergabe und den Rechten — nicht nach dem Feld.
Häufige Missverständnisse
Über den Autor
Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.