Leistung
Datenbanken: die Struktur unter der Oberfläche.
Ein Design lässt sich in zwei Wochen austauschen. Ein falsch geschnittenes Datenmodell begleitet Sie durch die gesamte Lebensdauer der Software.
Deshalb beginnen unsere Projekte mit der Frage, welche Dinge es gibt und wie sie zusammenhängen – und erst danach mit der Frage, wie sie aussehen.
Warum die Datenstruktur über die Lebensdauer entscheidet
Eine Anwendung bekommt in zehn Jahren drei neue Oberflächen. Die Daten darunter bleiben – und wachsen. Wenn dort am Anfang eine Vereinfachung eingebaut wurde, rächt sich das später an unerwarteter Stelle.
Ein Beispiel: Eine Adresse steht als ein einziges Textfeld in der Kundentabelle. Zwei Jahre später sollen Kunden eine zweite Lieferanschrift bekommen, und die Auswertung soll nach Postleitzahlgebieten sortieren. Beides geht nicht mehr ohne Umbau – und der betrifft jede Stelle im Programm, die diese Adresse anfasst. Mit einer eigenen Adresstabelle wäre es eine Sache von Stunden gewesen.
Woran Sie ein gutes Datenmodell erkennen
Jede Information steht an genau einer Stelle
Eine Kundenadresse existiert einmal, nicht in drei Tabellen. Ändert sie sich, ändert sie sich überall – von selbst, ohne Abgleich.
Die Datenbank schützt sich selbst
Eine Bestellung ohne Kunden lässt sich gar nicht erst anlegen. Solche Regeln liegen in der Datenbank und gelten auch dann, wenn ein Programm sie vergisst.
Vergangenheit bleibt lesbar
Auf einer Rechnung von 2023 steht der Preis von 2023, auch wenn der Artikel heute anders kostet. Keine Feinheit, sondern Buchhaltungspflicht.
Wachstum bremst nicht aus
Mit passenden Suchindizes bleibt eine Abfrage bei einer Million Zeilen so schnell wie bei tausend. Ohne sie wird die Anwendung langsam – und niemand versteht, warum.
Womit wir arbeiten
Wir setzen auf offene, verbreitete Technik – damit Sie von keinem Anbieter abhängen:
- PostgreSQLDie Datenbank
- Ein seit über 25 Jahren gepflegtes, quelloffenes Datenbanksystem. Relational heißt: Daten liegen in Tabellen, die über Verweise verbunden sind – Kunde, Bestellung, Position.
- Zugriffsregeln auf ZeilenebeneSicherheit in der Datenbank
- Regeln, die festlegen, welche Zeile ein bestimmter Nutzer überhaupt sehen darf. Sie gelten für jede Abfrage, egal aus welchem Programm sie kommt.
- MigrationenÄnderungen mit Historie
- Jede Strukturänderung ist eine nummerierte Datei. Sie läuft auf Test- und Produktivsystem in derselben Reihenfolge – nachvollziehbar und rückholbar.
- Sicherungen mit ZeitpunktZurück auf gestern 14:32 Uhr
- Moderne Verfahren stellen einen exakten Zeitpunkt wieder her, nicht nur den letzten nächtlichen Stand. Das ist der Unterschied zwischen einem verlorenen Tag und einer verlorenen Minute.
- Standort FrankfurtDaten in der EU
- Datenbank und Sicherungen liegen in europäischen Rechenzentren, mit Auftragsverarbeitungsvertrag des Anbieters.
Zugriffsregeln auf Zeilenebene – ohne Fachchinesisch
Der übliche Weg: Das Programm fragt die Datenbank nach allen Aufträgen und filtert selbst heraus, welche der angemeldete Nutzer sehen darf. Das funktioniert – solange jede Stelle im Programm daran denkt. Vergisst eine einzige Abfrage den Filter, sieht ein Kunde die Aufträge aller anderen.
Zugriffsregeln auf Zeilenebene drehen das um. Die Regel „Ein Nutzer sieht nur Zeilen, in denen er als Eigentümer eingetragen ist“ liegt in der Datenbank selbst. Fragt ein Programm nach allen Aufträgen, liefert die Datenbank trotzdem nur die erlaubten – auch wenn der Filter vergessen wurde, auch wenn ein Angreifer die Abfrage manipuliert.
Der Unterschied ist grundsätzlich: Eine Prüfung im Programmcode kann vergessen werden, eine Regel in der Datenbank nicht. Wie das mit Anmeldung, Verschlüsselung und Überwachung zusammenspielt, steht bei IT-Sicherheit.
Vom Gespräch zum Datenmodell
- 1
Substantive sammeln1 Termin
Sie erzählen Ihren Ablauf, wir notieren die Hauptwörter: Kunde, Angebot, Auftrag, Termin, Rechnung. Fast jedes wird später eine Tabelle.
- 2
Beziehungen klären2–4 Tage
Hat ein Kunde mehrere Anschriften? Kann ein Auftrag zu zwei Projekten gehören? Diese Fragen klingen unspektakulär und entscheiden über die halbe Struktur.
- 3
Rechte festlegen2–3 Tage
Welche Rolle darf welche Zeile sehen, ändern, löschen? Wir schreiben das als Tabelle auf, bevor eine einzige Regel entsteht.
- 4
Modell aufsetzen und prüfen1 Woche
Wir legen die Struktur an und füllen sie mit echten Beispieldaten, Sonderfälle eingeschlossen. Was hier auffällt, kostet später das Zehnfache.
- 5
Wiederherstellung testen1 Tag
Wir spielen eine Sicherung auf ein Testsystem zurück und messen, wie lange es dauert. Erst danach gilt die Sicherung als eingerichtet.
Ein Backup, das nie zurückgespielt wurde, ist kein Backup
Fast jeder Betrieb hat eine Sicherung. Deutlich weniger haben je geprüft, ob sie sich zurückspielen lässt. Der Ernstfall ist der schlechteste Zeitpunkt, um festzustellen, dass die Datei seit acht Monaten leer ist.
Wir klären deshalb zwei Zahlen vorab: Wie viel Datenverlust ist verkraftbar – eine Minute, eine Stunde, ein Tag? Und wie lange darf die Wiederherstellung dauern? Aus diesen Antworten ergibt sich das Sicherungsverfahren, nicht umgekehrt.
Datensparsamkeit als Prinzip
Die Datenschutz-Grundverordnung verlangt, nur zu erheben, was gebraucht wird. Jedes Feld, das nicht existiert, kann auch nicht gestohlen werden. Wie wir das umsetzen:
- Jedes Feld muss begründet sein: Wofür brauchen wir das Geburtsdatum?
- Löschfristen sind von Anfang an hinterlegt, nicht nachträglich gesucht
- Passwörter liegen als nicht umkehrbare Prüfsumme vor, nie im Klartext
- Auswertungen laufen auf anonymisierten Kopien, nicht auf dem Echtbestand
- Zugänge sind personengebunden – jeder Zugriff ist zuordenbar
- Was aufbewahrt werden muss, wird archiviert statt weiterverarbeitet
FAQ
Häufig gestellte Fragen
Für eine Liste, die eine Person pflegt, durchaus. Die Grenze ist erreicht, sobald mehrere gleichzeitig schreiben, Rechte nötig werden oder ein anderes Programm auf die Daten zugreifen soll. Spätestens wenn Dateien wie „Kunden_final_v3_neu.xlsx“ entstehen, arbeitet das Werkzeug gegen Sie.
In aller Regel ja. Wir übernehmen aus Tabellen, Altsystemen oder Exportdateien und bereinigen dabei, was sich über die Jahre angesammelt hat – doppelte Kunden, uneinheitliche Schreibweisen, Freitext in Zahlenfeldern. Diese Bereinigung weisen wir im Angebot getrennt aus, weil ihr Umfang von der Datenqualität abhängt.
Die Daten gehören Ihnen. Sie bekommen Zugangsdaten zur Datenbank und können jederzeit einen vollständigen Export ziehen – in einem offenen Format, das jede andere PostgreSQL-Datenbank einlesen kann. Es gibt kein Format, das nur wir lesen können, und keine Klausel, die einen Wechsel erschwert.
Eine Migration ist eine einzelne, dokumentierte Strukturänderung: „Tabelle Kunden bekommt ein Feld Steuernummer“. Sie liegt als Datei im Projekt und läuft auf jedem System in derselben Reihenfolge.
Ohne dieses Verfahren weicht das Testsystem irgendwann vom Produktivsystem ab, und niemand weiß, warum ein Fehler nur an einer Stelle auftritt.
Die Datenschutz-Grundverordnung verlangt das nicht ausdrücklich, innerhalb der EU ist die Lage aber deutlich einfacher – bei Anbietern aus Drittländern braucht es zusätzliche Prüfungen und Verträge. Wir richten deshalb standardmäßig in europäischen Rechenzentren ein. Was der Begriff im Einzelnen umfasst, steht im Glossar unter DSGVO.
Bevor gebaut wird: erst ordnen.
Ein Datenmodell-Termin lohnt sich auch dann, wenn wir die Software am Ende nicht bauen. Sie haben danach eine Struktur, mit der jeder Dienstleister arbeiten kann.
Termin vereinbaren