// technologien
Daten
Das Datenmodell überlebt in der Regel jedes Framework. Fehler an dieser Stelle lassen sich später nur mit Migrationen und Bereinigung korrigieren, deshalb entsteht das Modell vor der Oberfläche – abgeleitet aus den Fragen, die das System später beantworten soll.
// einsatz
Wie ich das einsetze
Modell aus den Fragen ableiten
Zuerst steht fest, welche Auswertungen und Abläufe gebraucht werden. Daraus ergeben sich Tabellen und Beziehungen – nicht umgekehrt.
Beziehungen in der Datenbank abbilden
Fremdschlüssel und Bedingungen sorgen dafür, dass ungültige Zustände gar nicht erst entstehen, statt sie in der Anwendung abfangen zu müssen.
Migrationen statt Handbetrieb
Schemaänderungen liegen als versionierte Migrationen im Repository. Jede Umgebung lässt sich damit reproduzierbar auf denselben Stand bringen.
Indizes nach Messung
Indizes entstehen aus tatsächlich langsamen Abfragen, nicht auf Verdacht. Jeder Index kostet Schreibleistung und Speicher.
// im detail
Die einzelnen Technologien
PostgreSQL
Meine Standardwahl für relationale Daten: strenge Typprüfung, Transaktionen, JSON-Felder für den Teil, der nicht ins feste Schema passt, sowie Erweiterungen etwa für Volltext- oder Vektorsuche.
MySQL
Weit verbreitet und auf fast jedem Hosting vorhanden. Für viele Anwendungen völlig ausreichend – und bei bestehenden Projekten meist ohnehin die Datenbank, die bereits läuft.
MongoDB
Dokumentorientiert und damit sinnvoll, wenn Datensätze unterschiedlich aufgebaut sind und keine feste Struktur erzwungen werden soll. Für Daten mit vielen Beziehungen bleibt eine relationale Datenbank die bessere Wahl.
Vektorsuche
Suche nach Bedeutung statt nach exakten Wörtern. Texte werden in Zahlenvektoren übersetzt, gesucht wird nach Nähe in diesem Raum. Grundlage für Suchfunktionen, die auch bei abweichender Wortwahl passende Treffer liefern.
Datenmodellierung
Die eigentliche Arbeit vor der Technik: Entitäten benennen, Beziehungen klären, Sonderfälle vorab durchdenken – mehrere Adressen, historische Stände, Löschungen. Diese Fragen tauchen im Betrieb ohnehin auf; vorher sind sie deutlich billiger.
// auswahl
Wonach ich auswähle
- 01
Struktur bekannt oder offen?
Feste Strukturen gehören in ein relationales Schema. Erst wenn sich die Form der Daten je Datensatz unterscheidet, wird ein dokumentorientierter Ansatz interessant.
- 02
Wie wird gelesen?
Ein System, das vor allem Listen und Filter zeigt, braucht andere Indizes als eines, das einzelne Datensätze nachschlägt.
- 03
Wie viel Betrieb ist realistisch?
Eine zusätzliche Datenbank bedeutet zusätzliche Backups, Updates und Überwachung. Das muss der Nutzen aufwiegen.
// faq
Häufige Fragen
Was passiert mit bestehenden Daten bei einem Umstieg?
Sie werden migriert. Dazu gehören ein Abgleich der Felder, das Bereinigen offensichtlicher Altlasten und ein Testlauf auf einer Kopie, bevor produktiv umgestellt wird.
Wo liegen die Daten?
Das entscheidet die Wahl von Hosting und Anbieter, nicht das eingesetzte Datenbanksystem. Serverstandort und Anbieter werden vor der Umsetzung festgelegt, damit später keine Überraschung entsteht.
Braucht jedes Projekt eine Vektorsuche?
Nein. Bei überschaubaren Datenmengen mit klarer Benennung reicht eine gute Volltextsuche. Vektorsuche lohnt sich, wenn Nutzer in eigenen Worten fragen und die Treffer trotzdem passen sollen.
// passend dazu
Wo das zum Einsatz kommt
Passt das zu deinem Vorhaben?
Welche Technologie sinnvoll ist, ergibt sich aus dem Vorhaben – nicht andersherum. Beschreib kurz, was entstehen soll; du bekommst eine Einschätzung dazu, was dafür passt und was nicht.
// weitere