Studio · Datenmodell
Ab hier hört der Baukasten auf, so zu tun, als könnte er es.
Text und Bilder kann jeder. Der Bruch kommt bei der ersten echten Liste: Produkte mit Kategorien, Termine mit Anmeldung, Objekte mit Zuständen, Referenzen filterbar nach Branche. Ab dort werden aus Datenfeldern Textblöcke, die zufällig gleich aussehen – und aus der Pflege wird ein Vollzeitjob. Was du brauchst, ist eine Struktur. Die entsteht hier im Gespräch, mit Entitäten, Feldern und echten Verweisen, auf einer Datenbank, die dir gehört.
01 — Das Modell
Deine Tabellen. Nicht drei Felder namens „Custom".
Eine Entität ist eine echte Tabelle auf deinem Server, mit Feldern, Datentypen, Vorgabewerten und Längen. Du beschreibst, was du brauchst; der Assistent legt es an und sagt dir hinterher, was entstanden ist – im Klartext, nicht als Kennungsliste.
- Texte, Zahlen, Kommazahlen, Datum, Langtext, HTML, Benutzer, Organisation – und Verweise auf andere Entitäten
- Jede Zeile trägt Kennung, Name, Beschreibung und Änderungszeitpunkt, ohne dass du sie erfinden musst
- Mandantenfähig von Haus aus: eine Spalte für die Organisation, und Abfragen filtern danach
- Felder liegen in einem Vorrat und lassen sich an mehrere Entitäten hängen – ein Statusfeld, überall gleich
02 — Das Freitextfeld
Jedes gewachsene System hat ein Feld namens „Bemerkung". Darin steht das halbe Geschäftsmodell.
So entsteht es: Es fehlt ein Feld, das Werkzeug kann keins, also nimmt jemand das, was da ist. Nach einem Jahr stehen drei Bedeutungen in derselben Spalte, und niemand traut sich mehr, sie auszuwerten. Drei Fälle, die man aus jedem Projekt kennt:
| Gebraucht wurde | Daraus wird im Baukasten | Hier |
|---|---|---|
| Ein Status je Vorgang | Ein Textfeld. Darin stehen „offen", „Offen", „OFFEN" und „warte auf Kunde". | Ein Feld mit festen Werten. Die Liste filtert danach, weil es etwas zu filtern gibt. |
| Die Kategorie eines Produkts | Ein Text mit dem Kategorienamen darin. Wird die Kategorie umbenannt, heißt sie an 240 Stellen weiter alt. | Ein Verweis auf die Entität Kategorie. Umbenennen an einer Stelle, überall richtig. |
| Zwei Termine je Anmeldung | „12.03. – 14.03." in einem Feld. Sortieren nach Datum: nicht möglich. | Zwei Datumsfelder. Sortieren, filtern und rechnen inklusive. |
03 — Verweise
Eine Kennung in einem Textfeld ist kein Verweis. Sie ist eine Ausrede.
Der häufigste Fehler in gewachsenen Modellen: irgendwo steht ein Text, in dem die Id einer anderen Zeile steckt. Das sieht aus wie eine Verbindung und ist keine – das Diagramm zeichnet keine Linie, der Verwendungsnachweis findet nichts, und beim Löschen warnt niemand.
Gehört ein Datensatz zu einem anderen, ist das Feld vom Typ der Zieltabelle. Danach kennt der Server die Verbindung – und alles, was darauf aufbaut, funktioniert von selbst.
Wird die Zielzeile umbenannt, zeigt jede Kopie ins Leere. Ein Verweis zeigt weiter auf dieselbe Zeile, egal wie sie heißt.
Er baut Verweise von sich aus und widerspricht, wenn ein Modell mit mehreren Entitäten kein einziges Verweisfeld hat. Das ist mit hoher Wahrscheinlichkeit falsch geschnitten, und dann soll das jemand hören, solange es noch billig ist.
Der Datentyp einer vorhandenen Spalte lässt sich nicht ändern: neues Feld, Werte übernehmen, altes abhängen. Deshalb wird beim Anlegen entschieden – erst die Zielentität, dann die verweisende.
04 — Das Diagramm
Man sieht sofort, ob ein Modell hält.
Entitäten als Kacheln, Verweise als Kanten. Ein Zoomregler legt auch ein Modell mit fünfzig Entitäten auf eine Bildschirmbreite; „Einpassen" rechnet den Maßstab aus der wirklichen Zeichenfläche. Ein Modell ohne Linien ist auf einen Blick als solches erkennbar – vier Kacheln, die einander nicht kennen, sind vier Tabellen und keine Anwendung.
- Kacheln zeigen Felder mit Datentyp, Kanten zeigen die Richtung
- Verwendungsnachweis: welche Seite, Vorlage oder Entität hängt an diesem Feld
- Wird neu gezeichnet, sobald jemand ein Feld anlegt – der Maßstab bleibt
05 — Vom Modell zur Seite
Eine Entität ist noch keine Anwendung. Zwei Zeilen Vorlage schon.
Listen, Einzelansichten, Formulare und Zähler entstehen aus dem Modell, nicht daneben. Du beschreibst die Ansicht, der Assistent schreibt Vorlage und Seite – und was dort steht, ist wieder normaler Quelltext deiner Instanz, den du lesen und ändern kannst.
- Listen mit Filter, Sortierung, Seitenwechsel – und Spalten über Verweise hinweg, ohne dass du einen Join schreibst
- Formulare, die schreiben: anlegen, ändern, löschen, mit Prüfung auf dem Server und nicht nur im Browser
- Zähler und Summen als eigenes Element – die Zahl auf der Startseite kommt aus derselben Quelle wie die Liste, also stimmen beide
- Adressparameter als Filter, mit Freigabeliste: der Server entscheidet, was gefiltert werden darf
06 — Was fehlt
Was das Datenmodell nicht ist.
Kein freies SQL, keine Indexverwaltung, keine gespeicherten Prozeduren. Wer das braucht, schreibt ein Plugin – dort stehen C# und der direkte Datenbankzugriff zur Verfügung.
Aus STRING wird kein Verweis. Das ist eine Eigenschaft des Servers und keine, die wir wegreden – deshalb steht die Warnung oben so deutlich.
Ein paar hundert Zeilen gehen im Gespräch. Für den Umzug eines Altbestands sprechen wir vorher über den Aufwand – das ist ein eigenes Angebot und keine versteckte Position.
Weiter im Studio
Wenn Vorlagen nicht mehr reichen, schreibst du C#.
Eigene Endpunkte, eigene Batchjobs, eigene HtmlItems – gegen die Serverversion deiner Instanz übersetzt.