4D-Architekturdesign: Ein vollständiger Leitfaden

Von HPO Software Learning Desk · Aktualisiert am 28. September 2026

Beim 4D-Architekturdesign handelt es sich um den Prozess der Strukturierung einer 4D-Datenbank (deren Tabellen, Felder, Beziehungen, Indizes und Zugriffsebenen), damit die Anwendung auch bei ihrem Wachstum schnell, wartbar und sicher bleibt. Ein gut geplantes 4D-Schema umfasst typischerweise fünf Kernentscheidungen: Tabellengranularität, Beziehungsstrategie, Primärschlüsseltyp, Indexspeicherort und Trennung von Daten von der Schnittstellenlogik. Wenn Sie dies von Anfang an richtig machen, können Sie in Zukunft kostspielige Migrationen vermeiden.

Wichtige Erkenntnisse

Das 4D-Architekturdesign trennt drei Belange: das Datenmodell (Tabellen, Felder, Beziehungen), die Geschäftslogikschicht (Methoden, Klassen, Trigger) und die Präsentationsschicht (Formulare, Listenfelder, Dialoge).
Der Beziehungstyp ist wichtiger als die Tabellenanzahl: Eine Viele-zu-Viele-Verknüpfung benötigt eine Verbindungstabelle, während eine Eins-zu-Viele-Verknüpfung ein Fremdschlüsselfeld und eine Beziehung verwendet.
Indizes beschleunigen Lesevorgänge, verlangsamen aber Schreibvorgänge – indizieren Sie Fremdschlüssel und jedes Feld, das in der WHERE-Klausel einer Abfrage verwendet wird, nicht jedes Feld.
Die ORDA-Ebene (Object Relational Data Access) von 4D verändert Ihre Einstellung zu Schemata: Gut benannte Tabellen und Felder werden zu lesbaren Datenklassen- und Attributnamen im Code.
Client-Server- oder Einzelbenutzer-Bereitstellung ist eine architektonische Entscheidung, kein nachträglicher Gedanke bei der Bereitstellung – sie wirkt sich auf Sperren, Caching und die Art und Weise aus, wie Sie Abfragen schreiben.
Vom ersten Tag an konsequent angewendete Namenskonventionen sparen mehr Refactoring-Zeit als jede andere einzelne Gewohnheit.

Was „4D-Architektur“ im Datenbankkontext bedeutet

4D-Architekturdesign bezieht sich auf das strukturelle Design einer Anwendung, die auf der 4D-Plattform (4th Dimension) basiert, der relationalen Datenbank und Low-Code-Entwicklungsumgebung, die ursprünglich 1984 von Laurent Ribardières Team veröffentlicht wurde und jetzt von 4D SAS verwaltet wird. Im Gegensatz zu einer reinen SQL-Datenbank bündelt 4D die Daten-Engine, eine Programmiersprache, einen Formular-Designer und einen Web-/REST-Server in einem Produkt – „Architektur“ umfasst hier also sowohl das Schema als auch die darüber liegenden Anwendungsschichten.

Der Begriff wird manchmal mit Architekturvisualisierung (4D BIM, Zeit als vierte Dimension im Gebäudeentwurf) verwechselt. Dieser Leitfaden behandelt den Software-Sinn: wie man eine 4D-Datenbank und ihre Anwendungsebenen anlegt. Wenn Sie auf der Suche nach Gebäudedesign sind, gelten die folgenden Konzepte nicht.

Die drei Schichten einer 4D-Anwendung

4D-Architekturentwurfsprojekte profitieren von einem expliziten Schichtenmodell. Durch die Aufteilung der Verantwortlichkeiten wird verhindert, dass eine wachsende App zu einem Gewirr aus Formularskripten wird.

Schicht 1 – Das Datenmodell

Das Datenmodell ist der Satz von Tabellen, Feldern, Beziehungen und Indizes, die in der 4D-Strukturdatei gespeichert sind. Diese Ebene sollte keinen Benutzeroberflächencode und keine Geschäftsregeln enthalten, die anderswo existieren könnten. Feldtypen (Text, Ganzzahl, reelle Zahl, Datum, Uhrzeit, Boolescher Wert, Blob, Objekt, Bild) und Feldlängen sind hier festgelegt, und ihre spätere Änderung in einer Live-Datenbank erfordert Sorgfalt.

Schicht 2 – Geschäftslogik

Die Geschäftslogik lebt in Projektmethoden, Klassen und Tabellentriggern. Im modernen 4D können Sie mit Klassen (eingeführt mit 4D v18 R3 und seitdem erweitert) wiederverwendbaren, testbaren Code schreiben, anstatt die Logik über Formularmethoden zu verteilen. Ein Trigger für eine Tabelle wird beim Erstellen, Speichern und Löschen ausgelöst – nützlich für Audit-Trails, aber ein Trigger, der die Benutzeroberfläche aufruft, funktioniert in Headless-Serverkontexten nicht.

Verwandte: — Eine einfache Tabellenkalkulationsschnittstelle, die auf einer echten relationalen Datenbank aufbaut, mit Automatisierungen, Ansichten und gemeinsam nutzbaren Schnittstellen..

Schicht 3 – Präsentation

Die Präsentation umfasst Formulare, Listenfelder, Eingabedialoge und alle Web- oder REST-Ausgaben. 4D-Formulare binden direkt an Felder und Variablen, was praktisch ist, aber dazu anregt, Logik in das Formular einzubauen. Formmethoden schlank zu halten – eine Klassenmethode aufzurufen und das Ergebnis anzuzeigen – ist in den meisten 4D-Projekten der größte Gewinn für die Wartbarkeit.

Entwerfen des Datenmodells: Tabellen, Beziehungen und Schlüssel

Datenmodellierungsentscheidungen im 4D-Architekturdesign folgen relationalen Prinzipien, auf denen 4D-spezifische Mechanismen basieren.

Tabellengranularität auswählen

Eine Tabelle sollte einen Entitätstyp darstellen. Die Aufteilung einer „customer“-Tabelle in „customer“ und „customer_address“ ist sinnvoll, wenn ein Kunde mehrere Adressen haben kann; eine Zusammenführung ist dann sinnvoll, wenn pro Kunde genau eine Adresse vorhanden ist und keine Wiederverwendung erfolgt. Eine übermäßige Normalisierung in viele kleine Tabellen erhöht die Anzahl der Beziehungen und Verknüpfungen, was die Leistung in Listenansichten beeinträchtigt.

Wenn Sie einkaufen: — Ein , der sich in die breitere Zoho-Suite einfügt und Preise pro Benutzer und nicht pro App berechnet..

Beziehungstypen

4D unterstützt automatische Beziehungen, die im Struktureditor definiert werden, und manuelle Beziehungen, die im Code erstellt werden. Die häufigsten Muster:

Beziehung	4D-Umsetzung	Typische Verwendung
Eins-zu-viele	Fremdschlüsselfeld auf der „vielen“-Seite plus einer Relation	Rechnung → Rechnungsposten
Viele-zu-viele	Verbindungstabelle mit zwei Fremdschlüsseln	Produkte ↔ Lieferanten
Eins-zu-eins	Gemeinsamer Primärschlüssel oder ein eindeutiger Fremdschlüssel	Benutzer → Benutzerprofil
Selbstreferenzierung	Fremdschlüssel, der auf dieselbe Tabelle zurückweist	Mitarbeiter → Manager

Primärschlüsselstrategie

4D bietet automatisch inkrementierende Longint-Primärschlüssel und UUID-Primärschlüssel (Text). Longint-Schlüssel sind kompakt und lassen sich schnell indizieren; UUIDs sind weltweit eindeutig, was wichtig ist, wenn Daten von mehreren Standorten zusammengeführt oder mit externen Systemen synchronisiert werden. Ein üblicher Kompromiss ist ein interner Longint-Schlüssel plus ein separates eindeutiges Textfeld für die „externe Referenz“.

Indizierung und Abfrageleistung

Indizes sind der Leistungshebel mit der höchsten Hebelwirkung im 4D-Architekturdesign und lassen sich auch am einfachsten überbeanspruchen.

Was indiziert werden soll

Indizieren Sie jedes Feld, das als Fremdschlüssel einer Beziehung verwendet wird, jedes Feld, das häufig in den Suchkriterien einer Abfrage verwendet wird, und jedes Feld, das zum Sortieren in großen Listenfeldern verwendet wird. 4D unterstützt Standard-B-Tree-Indizes, Schlüsselwort-Indizes für die wortbasierte Textsuche und zusammengesetzte Indizes, die mehrere Felder abdecken.

Was nicht indiziert werden sollte

Jeder Index erhöht die Schreibkosten und den Speicherplatz. Das Indizieren eines booleschen Felds mit zwei möglichen Werten hilft selten. Die Indizierung eines Felds, das immer nur als Teil einer vollständigen Datensatzanzeige gelesen wird, bringt keinen Gewinn. Überprüfen Sie die Indizes, nachdem die Anwendung tatsächliche Nutzungsmuster aufweist, anstatt im Voraus zu raten.

Abfragestrategie

ORDA-Abfragen („ds.Invoice.query(“Status = :1”; “Open”)`) sind im Allgemeinen den klassischen QUERY-Befehlen für neuen Code vorzuziehen, da sie Entitätsauswahlen zurückgeben, die ohne erneute Abfrage sortiert, gefiltert und zwischen Methoden übergeben werden können. Bei sehr großen Tabellen sorgt die Einschränkung der Abfrage mit indizierten Kriterien vor der Anwendung nicht indizierter Filter dafür, dass die Antwortzeiten vorhersehbar bleiben.

Verwandte: — Ein Datenbank-Builder ohne Code für Portale, Verzeichnisse und interne Tools – mit Pauschalpreisen statt Gebühren pro Benutzer..

ORDA und moderne 4D-Architektur

ORDA (Object Relational Data Access) ist die objektorientierte Datenzugriffsschicht von 4D, die in 4D v17 eingeführt wurde. Es stellt Tabellen als Datenklassen und Datensätze als Entitäten bereit, sodass eine Tabelle mit dem Namen „Invoice“ zu „ds.Invoice“ und ein Feld mit dem Namen „TotalNet“ zu „$invoice.TotalNet“ wird.

Dies hat eine architektonische Konsequenz für das 4D-Architekturdesign: Tabellen- und Feldnamen sind jetzt Teil Ihrer öffentlichen API. Das Umbenennen eines Felds führt zu Code-Fehlern, die bereits zur Kompilierungszeit sichtbar sind. Eine inkonsistente Benennung macht den ORDA-Code jedoch schwer lesbar. Die Übernahme einer Konvention – einzelne Tabellennamen, PascalCase-Felder, keine Abkürzungen – zahlt sich sofort aus.

ORDA unterstützt auch clientseitige Entitätsauswahlen, die nur teilweise geladen sind, wodurch sich das Leistungsprofil von Listenbildschirmen ändert. Ein an eine Entitätsauswahl gebundenes Listenfeld kann Tausende von Zeilen anzeigen, ohne jeden Datensatz zu laden, vorausgesetzt, die dahinter stehende Abfrage ist indiziert.

Unsere Wahl: — Die langlebige für Teams, die benutzerdefinierte Apps auf Desktop, Web und Mobilgeräten aus einer einzigen Datei benötigen..

Client-Server-, Einzelbenutzer- und Web-Bereitstellung

Die Bereitstellungstopologie prägt das Design der 4D-Architektur stärker, als viele Entwickler erwarten.

Einzelbenutzeranwendungen führen die Daten-Engine und die Schnittstelle in einem Prozess aus. Die Sperrung von Datensätzen ist trivial; Bei der Leistungsoptimierung geht es hauptsächlich um die Geschwindigkeit der lokalen Festplatte.

Client-Server trennt den 4D Server (Daten-Engine) vom 4D Client (Schnittstelle). Datensätze werden auf dem Server gesperrt und die Netzwerk-Round-Trip-Kosten für jede Abfrage werden erheblich. Architekturen, die viele kleine Abfragen pro Bildschirm ausgeben, schneiden hier schlecht ab; Batch-Abfragen und die Verwendung von Entitätsauswahlen reduzieren Roundtrips.

Web- und REST-Bereitstellungen stellen dasselbe Datenmodell über den REST-Server von 4D oder über kompilierte Webmethoden bereit. Die Sicherheit rückt in den Vordergrund: Der Zugriff auf Tabellen und Felder muss durch Rollen und Berechtigungen eingeschränkt werden, und jede Geschäftsregel, die nur in einer Formularmethode durchgesetzt wird, wird für Web-Clients praktisch nicht durchgesetzt.

Namenskonventionen und Dokumentation

Eine einheitliche Benennung ist unscheinbar, aber entscheidend für das Design der 4D-Architektur. Eine praktikable Konvention für 4D:

Tabellen: Substantive im Singular, PascalCase („Customer“, „InvoiceLine“).
Felder: PascalCase, ohne Typpräfixe („InvoiceDate“, nicht „dInvDate“).
Beziehungen: benannt nach der Zieltabelle („Customer_Invoices“).
Methoden: Verb zuerst („CreateInvoice“, „RecalculateTotals“).
Klassen: Substantiv zuerst („InvoiceService“, „TaxCalculator“).

Die Dokumentation des Schemas – sogar als einzelne Markdown-Datei, in der jede Tabelle, ihr Zweck und ihre wichtigsten Beziehungen aufgeführt sind – erleichtert das Onboarding und zukünftige Migrationen erheblich. Der Struktureditor von 4D zeigt Beziehungen grafisch an, erklärt jedoch nicht, warum eine Tabelle existiert.

Häufige Fehler beim Design der 4D-Architektur

Geschäftslogik in Formularmethoden einfügen. Formularmethoden können nicht aus Webkontexten oder geplanten Aufgaben aufgerufen werden, daher muss die dort eingeschlossene Logik dupliziert werden.

Verwendung auswahlbasierter klassischer Befehle im gesamten neuen Code. Klassische Auswahlen sind prozessgebunden und lassen sich nicht gut zwischen Prozessen übertragen; ORDA-Entitätsauswahlen sind flexibler.

Überspringen der Verknüpfungstabelle. Das Speichern mehrerer Werte in einem einzigen Textfeld (durch Kommas getrennte IDs) macht die Indizierung zunichte und macht die Berichterstellung mühsam.

Alles indizieren. Die Schreibleistung nimmt ab und der Nutzen wird nur selten realisiert.

Privilegien werden bis zur Bereitstellung ignoriert. Das Nachrüsten eines Sicherheitsmodells auf einer fertigen Anwendung ist erheblich schwieriger, als es zusammen mit dem Schema zu entwerfen.

So entscheiden Sie: Eine praktische Checkliste

Bevor Sie Ihren 4D-Architekturentwurf erstellen, gehen Sie die folgenden Fragen durch:

Wie viele gleichzeitige Benutzer und werden sie sich über ein LAN, WAN oder das Internet verbinden?
Welche Entitäten haben eine natürliche Eins-zu-viele-Beziehung und welche benötigen Verbindungstabellen?
Welche Felder werden in Suchkriterien oder Sortierreihenfolgen in großen Tabellen angezeigt?
Welche Geschäftsregeln müssen unabhängig vom Einstiegspunkt (Formular, Web, Import) gelten?
Werden Daten jemals mit einem anderen System zusammengeführt, wofür UUID-Schlüssel erforderlich sind?
Wer behält dies in zwei Jahren bei und wird die Benennung für ihn sinnvoll sein?

Antworten auf diese sechs Fragen bestimmen die meisten strukturellen Entscheidungen in einem 4D-Projekt.

Weiterführende Literatur

Die offizielle 4D-Dokumentation auf Developer.4d.com behandelt ORDA, Klassen, Berechtigungen und Bereitstellung im Detail. Informationen zu den Grundlagen der relationalen Modellierung, die unabhängig von der Plattform gelten, finden Sie im Wikipedia-Artikel zur Datenbanknormalisierung. Für den breiteren Kontext von Low-Code- und Rapid Application Development-Plattformen ist der Wikipedia-Eintrag zu Low-Code-Entwicklungsplattformen ein sinnvoller Ausgangspunkt. 4D SAS veröffentlicht außerdem Versionshinweise und Migrationshandbücher, die beschreiben, wann ORDA, Klassen und andere Designfunktionen der 4D-Architektur eingeführt wurden.

Häufig gestellte Fragen

Was ist 4D-Architekturdesign?

4D-Architekturdesign ist der Prozess der Planung der Struktur einer 4D-Anwendung (4. Dimension): ihre Tabellen, Felder, Beziehungen, Indizes, Geschäftslogikschicht und Präsentationsschicht. Sie bestimmt, wie die Anwendung funktioniert, wie einfach sie geändert werden kann und wie sicher sie auf Desktop-, Client-Server- oder Web-Clients bereitgestellt werden kann.

Ist 4D-Architektur dasselbe wie 4D-BIM?

Nein. 4D BIM fügt der Gebäudeinformationsmodellierung für die Bauplanung Zeit als vierte Dimension hinzu. Unter 4D-Architektur im Sinne von Software versteht man das Entwerfen von Anwendungen auf der 4D-Datenbankplattform. Die beiden Felder haben eine Abkürzung, aber sonst nichts gemeinsam.

Soll ich ORDA oder klassische 4D-Befehle verwenden?

ORDA ist die beste Option für Neuentwicklungen. Es gibt Entitätsauswahlen zurück, die zwischen Methoden übergeben, sortiert und gefiltert werden können, ohne dass eine erneute Abfrage erforderlich ist, und stellt Tabellen und Felder als Eigenschaften lesbarer Objekte bereit. Klassische auswahlbasierte Befehle sind in Legacy-Code und in einigen Sonderfällen immer noch nützlich.

Wie viele Indizes sollte eine 4D-Tabelle haben?

Es gibt keine feste Nummer. Indizieren Sie Fremdschlüssel, Felder, die in allgemeinen Suchkriterien verwendet werden, und Felder, die zum Sortieren großer Listen verwendet werden. Vermeiden Sie die Indizierung von Feldern mit geringer Kardinalität, wie z. B. booleschen Werten oder Statusfeldern mit zwei oder drei Werten, da die Schreibkosten normalerweise den Lesevorteil überwiegen.

Welchen Primärschlüsseltyp sollte ich in 4D wählen?

Automatisch inkrementierende Longint-Schlüssel sind kompakt und schnell und eignen sich für Single-Site-Anwendungen. UUID-Textschlüssel sind größer, aber global eindeutig, was beim Zusammenführen von Daten von mehreren Standorten oder bei der Integration mit externen Systemen wichtig ist. Viele Projekte verwenden intern einen Longint-Schlüssel sowie ein eindeutiges externes Referenzfeld.

Kann ich das 4D-Datenmodell nach der Bereitstellung ändern?

Ja, aber mit Vorsicht. Das Hinzufügen von Tabellen, Feldern und Indizes ist im Allgemeinen unkompliziert. Das Ändern von Feldtypen, das Umbenennen von Feldern, die von ORDA-Code verwendet werden, oder das Umstrukturieren von Beziehungen in einer Live-Datenbank erfordert eine geplante Migration, die idealerweise zuerst an einer Kopie der Produktionsdaten getestet wird.