4D-architectuurontwerp: een complete gids

Door HPO Software Learning Desk · Bijgewerkt op 27 september 2026

4D-architectonisch ontwerp is het proces van het structureren van een 4D-database (de tabellen, velden, relaties, indexen en toegangsniveaus) zodat de applicatie snel, onderhoudbaar en veilig blijft naarmate deze groeit. Een goed gepland 4D-schema omvat doorgaans vijf kernbeslissingen: tabelgranulariteit, relatiestrategie, primair sleuteltype, indexlocatie en scheiding van gegevens van interfacelogica. Als u dit vanaf het begin goed doet, kunt u kostbare migraties in de toekomst voorkomen.

Belangrijkste punten

Het 4D-architectuurontwerp scheidt drie aandachtspunten: het datamodel (tabellen, velden, relaties), de bedrijfslogicalaag (methoden, klassen, triggers) en de presentatielaag (formulieren, keuzelijsten, dialoogvensters).
Het type relatie is belangrijker dan het aantal tabellen: een veel-op-veel-koppeling heeft een knooppunttabel nodig, terwijl een één-op-veel-koppeling een refererend sleutelveld plus een relatie gebruikt.
Indexen versnellen het lezen maar vertragen het schrijven — indexeer externe sleutels en elk veld dat wordt gebruikt in de WHERE-clausule van een query, niet elk veld.
De ORDA-laag (Object Relational Data Access) van 4D verandert de manier waarop u over schema denkt: goed benoemde tabellen en velden worden leesbare dataklasse- en attribuutnamen in code.
Client-server-implementatie versus single-user-implementatie is een architectonische beslissing, geen bijzaak bij de implementatie; het beïnvloedt de vergrendeling, caching en de manier waarop u query’s schrijft.
Naamgevingsconventies die vanaf de eerste dag consistent worden toegepast, besparen meer refactoringstijd dan welke andere gewoonte dan ook.

Wat “4D-architectuur” betekent in een databasecontext

4D-architectuurontwerp verwijst naar het structurele ontwerp van een applicatie gebouwd op het 4D-platform (4e dimensie), de relationele database en low-code ontwikkelomgeving die oorspronkelijk in 1984 door het team van Laurent Ribardière werd uitgebracht en nu wordt onderhouden door 4D SAS. In tegenstelling tot een pure SQL-database bundelt 4D de data-engine, een programmeertaal, een formulierontwerper en een web/REST-server in één product. ‘architectuur’ omvat hier dus zowel het schema als de applicatielagen die erbovenop zitten.

De term wordt soms verward met architecturale visualisatie (4D BIM, tijd als vierde dimensie in het ontwerpen van gebouwen). Deze gids behandelt de softwarezin: hoe u een 4D-database en de applicatielagen ervan opmaakt. Als u op zoek bent naar bouwontwerp, zijn de onderstaande concepten niet van toepassing.

De drie lagen van een 4D-applicatie

4D-architectuurontwerpprojecten profiteren van een expliciet gelaagd model. Door de verantwoordelijkheden te splitsen, voorkom je dat een groeiende app verandert in een wirwar van formulierscripts.

Laag 1 — Het gegevensmodel

Het datamodel is de set tabellen, velden, relaties en indexen die zijn opgeslagen in het 4D-structuurbestand. Deze laag mag geen gebruikersinterfacecode bevatten en geen bedrijfsregels die elders zouden kunnen voorkomen. Veldtypen (tekst, geheel getal, reëel, datum, tijd, Boolean, blob, object, afbeelding) en veldlengtes liggen hier vast, en het later wijzigen ervan in een live database vereist zorg.

Laag 2 — Bedrijfslogica

Bedrijfslogica leeft in projectmethoden, klassen en tabeltriggers. In moderne 4D kunt u met klassen (geïntroduceerd in 4D v18 R3 en sindsdien uitgebreid) herbruikbare, testbare code schrijven in plaats van logica over formuliermethoden te verspreiden. Een trigger op een tabel wordt geactiveerd bij het maken, opslaan en verwijderen - handig voor audittrails, maar een trigger die de gebruikersinterface aanroept, zal breken in headless servercontexten.

Gerelateerd: — Het langlopende relationele databaseplatform voor teams die aangepaste apps nodig hebben op desktop, internet en mobiel vanuit één bestand..

Laag 3 — Presentatie

Presentatie omvat formulieren, keuzelijsten, invoerdialoogvensters en alle web- of REST-uitvoer. 4D-formulieren binden rechtstreeks aan velden en variabelen, wat handig is, maar moedigt aan om logica in het formulier te plaatsen. Het beperkt houden van formuliermethoden – het aanroepen van een klassenmethode en het weergeven van het resultaat – is de grootste overwinning op het gebied van onderhoudbaarheid in de meeste 4D-projecten.

Het gegevensmodel ontwerpen: tabellen, relaties en sleutels

Beslissingen over datamodellering bij het ontwerpen van 4D-architectuur volgen relationele principes, met daarop 4D-specifieke mechanica.

Tabelgranulariteit kiezen

Een tabel moet één entiteitstype vertegenwoordigen. Het splitsen van een “klant”-tabel in “klant” en “klant_adres” is zinvol als een klant meerdere adressen kan hebben; samenvoegen is zinvol als er per klant precies één adres is en er geen sprake is van hergebruik. Overnormaliseren in veel kleine tabellen vergroot het aantal relaties en joins, wat de prestaties in lijstweergaven ten koste gaat.

Onze keuze: — Een spreadsheet-eenvoudige interface bovenop een echte relationele database, met automatiseringen, weergaven en deelbare interfaces..

Relatietypen

4D ondersteunt automatische relaties die zijn gedefinieerd in de structuureditor en handmatige relaties die in code zijn gemaakt. De gemeenschappelijke patronen:

Relatie	4D-implementatie	Typisch gebruik
Eén-op-veel	Foreign key-veld aan de “veel”-kant plus een relatie	Factuur → Factuurregels
Veel-op-veel	Verbindingstabel met twee externe sleutels	Producten ↔ Leveranciers
Eén op één	Gedeelde primaire sleutel of een unieke externe sleutel	Gebruiker → Gebruikersprofiel
Zelfreferentie	Externe sleutel die terugwijst naar dezelfde tabel	Medewerker → Leidinggevende

Primaire sleutelstrategie

4D biedt automatisch oplopende primaire longint-sleutels en primaire UUID-sleutels (tekst). Longint-sleutels zijn compact en snel te indexeren; UUID’s zijn wereldwijd uniek, wat van belang is bij het samenvoegen van gegevens van meerdere sites of bij het synchroniseren met externe systemen. Een veelvoorkomend compromis is een interne longint-sleutel plus een afzonderlijk, uniek tekstveld voor “externe referentie”.

Indexering en queryprestaties

Indexen zijn de prestatiehefboom met de hoogste hefboomwerking in het ontwerp van 4D-architectuur, en ook het gemakkelijkst om te veel toe te passen.

Wat te indexeren

Indexeer elk veld dat wordt gebruikt als refererende sleutel voor een relatie, elk veld dat vaak wordt gebruikt in de zoekcriteria van een query, en elk veld dat wordt gebruikt voor het sorteren in grote keuzelijsten. 4D ondersteunt standaard B-tree-indexen, trefwoordindexen voor op woorden gebaseerde tekstzoekopdrachten en samengestelde indexen die meerdere velden bestrijken.

Wat u niet moet indexeren

Elke index voegt schrijfkosten en opslag toe. Het indexeren van een Booleaans veld met twee mogelijke waarden helpt zelden. Het indexeren van een veld dat alleen wordt gelezen als onderdeel van een volledige recordweergave voegt overhead toe zonder enige winst. Bekijk indexen nadat de applicatie echte gebruikspatronen heeft, in plaats van vooraf te raden.

Zoekstrategie

ORDA-query’s (ds.Invoice.query("Status = :1"; "Open")) hebben over het algemeen de voorkeur boven klassieke QUERY-opdrachten voor nieuwe code, omdat ze entiteitsselecties retourneren die kunnen worden gesorteerd, gefilterd en doorgegeven tussen methoden zonder opnieuw te hoeven zoeken. Voor zeer grote tabellen zorgt het beperken van de query met geïndexeerde criteria voordat niet-geïndexeerde filters worden toegepast ervoor dat de responstijden voorspelbaar blijven.

Gerelateerd: — Low-code app-ontwikkeling op bedrijfsniveau, aangesloten op Microsoft 365, Dataverse en Power Automate..

ORDA en moderne 4D-architectuur

ORDA (Object Relational Data Access) is de objectgeoriënteerde gegevenstoegangslaag van 4D, geïntroduceerd in 4D v17. Het stelt tabellen bloot als dataklassen en records als entiteiten, dus een tabel met de naam Invoice wordt ds.Invoice en een veld met de naam TotalNet wordt $invoice.TotalNet.

Dit heeft een architectonisch gevolg voor het 4D-architectuurontwerp: tabel- en veldnamen maken nu deel uit van uw openbare API. Het hernoemen van een veld breekt code op een manier die zichtbaar is tijdens het compileren, maar inconsistente naamgeving maakt ORDA-code moeilijk te lezen. Het aannemen van een conventie – enkelvoudige tabelnamen, PascalCase-velden, geen afkortingen – loont onmiddellijk.

ORDA ondersteunt ook entiteitselecties aan de clientzijde die slechts gedeeltelijk worden geladen, waardoor het prestatieprofiel van lijstschermen verandert. Een keuzelijst die aan een entiteitsselectie is gebonden, kan duizenden rijen weergeven zonder elke record te laden, ervan uitgaande dat de zoekopdracht erachter is geïndexeerd.

Lezersfavoriet: — Een databasebouwer zonder code, gericht op portals, directory's en interne tools, met vaste prijzen in plaats van kosten per gebruiker..

Client-server, single-user en webimplementatie

De implementatietopologie geeft meer vorm aan het 4D-architectuurontwerp dan veel ontwikkelaars verwachten.

Single-user-applicaties voeren de data-engine en interface in één proces uit. Vergrendelen is triviaal; prestatie-afstemming gaat meestal over de lokale schijfsnelheid.

Client-server splitst de 4D Server (data-engine) van de 4D Client (interface). Records worden op de server vergrendeld en de netwerkkosten voor elke zoekopdracht worden aanzienlijk. Architecturen die veel kleine zoekopdrachten per scherm uitvoeren, presteren hier slecht; het batchen van query’s en het gebruik van entiteitsselecties vermindert round trips.

Web- en REST-implementatie maakt hetzelfde datamodel zichtbaar via de REST-server van 4D of via gecompileerde webmethoden. Beveiliging komt op de voorgrond: de toegang tot tabellen en velden moet worden beperkt door middel van rollen en privileges, en elke bedrijfsregel die alleen in een formuliermethode wordt afgedwongen, wordt feitelijk niet afgedwongen voor webclients.

Naamgevingsconventies en documentatie

Consistente naamgeving is niet glamoureus, maar doorslaggevend voor 4D-architectuurontwerp. Een werkbare conventie voor 4D:

Tabellen: enkelvoudige zelfstandige naamwoorden, PascalCase (“Klant”, “InvoiceLine”).
Velden: PascalCase, zonder typevoorvoegsels (“InvoiceDate”, niet “dInvDate”).
Relaties: benoemd volgens de bestemmingstabel (“Customer_Invoices”).
Methoden: werkwoord eerst (“CreateInvoice”, “RecalculateTotals”).
Klassen: zelfstandig naamwoord eerst (“InvoiceService”, “TaxCalculator”).

Het documenteren van het schema – zelfs als één enkel Markdown-bestand waarin elke tabel, het doel en de belangrijkste relaties ervan worden vermeld – maakt onboarding en toekomstige migraties veel eenvoudiger. De structuureditor van 4D toont relaties grafisch, maar verklaart niet waarom een tabel bestaat.

Veelvoorkomende ontwerpfouten in de 4D-architectuur

Bedrijfslogica in formuliermethoden plaatsen. Formuliermethoden kunnen niet worden aangeroepen vanuit webcontexten of geplande taken, dus logica die daar vastzit, moet worden gedupliceerd.

Het gebruik van op selectie gebaseerde klassieke commando’s in de nieuwe code. Klassieke selecties zijn procesgebonden en reizen niet goed tussen processen; ORDA-entiteitsselecties zijn flexibeler.

De verbindingstabel overslaan. Het opslaan van meerdere waarden in één tekstveld (door komma’s gescheiden ID’s) maakt indexering overbodig en maakt rapportage pijnlijk.

Alles indexeren. De schrijfprestaties gaan achteruit en het voordeel wordt zelden gerealiseerd.

Rechten negeren tot de implementatie. Het achteraf inbouwen van een beveiligingsmodel in een voltooide applicatie is aanzienlijk moeilijker dan het ontwerpen ervan naast het schema.

Hoe te beslissen: een praktische checklist

Voordat u uw 4D-architectuurontwerp gaat maken, moet u deze vragen beantwoorden:

Hoeveel gelijktijdige gebruikers, en zullen zij verbinding maken via een LAN, WAN of internet?
Welke entiteiten hebben een natuurlijke één-op-veel-relatie, en welke hebben verbindingstabellen nodig?
Welke velden verschijnen in zoekcriteria of sorteervolgordes in grote tabellen?
Welke bedrijfsregels moeten gelden, ongeacht het toegangspunt (formulier, web, import)?
Zullen gegevens ooit worden samengevoegd met een ander systeem, waarvoor UUID-sleutels nodig zijn?
Wie onderhoudt dit over twee jaar, en zal de naamgeving voor hen zinvol zijn?

De antwoorden op deze zes vragen bepalen de meeste structurele beslissingen in een 4D-project.

Verder lezen

De officiële 4D-documentatie op developer.4d.com behandelt ORDA, klassen, privileges en implementatie in detail. Voor de basisprincipes van relationele modellering die ongeacht het platform van toepassing zijn, zie het Wikipedia-artikel over databasenormalisatie. Voor de bredere context van low-code en snelle applicatie-ontwikkelplatforms is het Wikipedia-artikel over low-code-ontwikkelplatforms een redelijk uitgangspunt. 4D SAS publiceert ook release-opmerkingen en migratiegidsen die beschrijven wanneer ORDA, klassen en andere ontwerpfuncties voor 4D-architectuur werden geïntroduceerd.

Veelgestelde vragen

Wat is 4D-architectuurontwerp?

4D-architectuurontwerp is het proces van het plannen van de structuur van een 4D-toepassing (4e dimensie): de tabellen, velden, relaties, indexen, bedrijfslogicalaag en presentatielaag. Het bepaalt hoe de applicatie presteert, hoe gemakkelijk deze kan worden gewijzigd en hoe veilig deze kan worden ingezet op desktop-, client-server- of webclients.

Is 4D-architectuur hetzelfde als 4D BIM?

Nee. 4D BIM voegt tijd toe als vierde dimensie aan het modelleren van bouwinformatie voor bouwplanning. 4D-architectuur in softwarematige zin verwijst naar het ontwerpen van applicaties op het 4D-databaseplatform. De twee velden delen een afkorting, maar verder niets.

Moet ik ORDA of klassieke 4D-opdrachten gebruiken?

Bij nieuwe ontwikkelingen is ORDA de beste optie. Het retourneert entiteitselecties die tussen methoden kunnen worden doorgegeven, gesorteerd en gefilterd zonder dat er opnieuw een query op moet worden uitgevoerd, en stelt tabellen en velden bloot als eigenschappen van leesbare objecten. Klassieke, op selectie gebaseerde opdrachten zijn nog steeds nuttig in oudere code en in sommige speciale gevallen.

Hoeveel indexen moet een 4D-tabel hebben?

Er is geen vast aantal. Indexeer externe sleutels, velden die worden gebruikt in algemene zoekcriteria en velden die worden gebruikt om grote lijsten te sorteren. Vermijd het indexeren van velden met een lage kardinaliteit, zoals booleaanse waarden of statusvelden met twee of drie waarden, omdat de schrijfkosten doorgaans groter zijn dan het leesvoordeel.

Welk type primaire sleutel moet ik kiezen in 4D?

Automatisch oplopende lange sleutels zijn compact en snel, en geschikt voor toepassingen op één locatie. UUID-tekstsleutels zijn groter maar globaal uniek, wat van belang is bij het samenvoegen van gegevens van meerdere sites of bij de integratie met externe systemen. Veel projecten gebruiken intern een longint-sleutel plus een uniek extern referentieveld.

Kan ik het 4D-datamodel na de implementatie wijzigen?

Ja, maar met zorg. Het toevoegen van tabellen, velden en indexen is over het algemeen eenvoudig. Het wijzigen van veldtypen, het hernoemen van velden die door ORDA-code worden gebruikt, of het herstructureren van relaties in een live database vereist een geplande migratie, idealiter eerst getest op een kopie van productiegegevens.