4D-arkitekturdesign: En komplet vejledning

Af HPO Software Learning Desk · Opdateret 28. september 2026

4D-arkitektonisk design er processen med at strukturere en 4D-database (dens tabeller, felter, relationer, indekser og adgangsniveauer), så applikationen forbliver hurtig, vedligeholdelsesvenlig og sikker, mens den vokser. Et velplanlagt 4D-skema involverer typisk fem kernebeslutninger: tabelgranularitet, relationsstrategi, primærnøgletype, indeksplacering og adskillelse af data fra interfacelogik. At få dette rigtigt fra begyndelsen vil hjælpe dig med at undgå dyre migreringer i fremtiden.

Key Takeaways

4D-arkitekturdesign adskiller tre hensyn: datamodellen (tabeller, felter, relationer), forretningslogiklaget (metoder, klasser, triggere) og præsentationslaget (formularer, listebokse, dialogbokse).
Relationstype betyder mere end tabelantal: et mange-til-mange-link har brug for en forbindelsestabel, mens et en-til-mange-link bruger et fremmednøglefelt plus en relation.
Indekser øger læsehastigheden, men gør skrivning langsommere - indekser fremmednøgler og ethvert felt, der bruges i en forespørgsels WHERE-klausul, ikke alle felter.
4D’s ORDA (Object Relational Data Access) lag ændrer, hvordan du tænker om skema: velnavngivne tabeller og felter bliver læsbare dataklasse- og attributnavne i kode.
Klient-server versus enkeltbruger-implementering er en arkitektonisk beslutning, ikke en eftertanke ved implementering - det påvirker låsning, caching og hvordan du skriver forespørgsler.
Navngivningskonventioner, der anvendes konsekvent fra dag ét, sparer mere refaktoreringstid end nogen anden enkelt vane.

Hvad “4D-arkitektur” betyder i en databasekontekst

4D-arkitekturdesign refererer til det strukturelle design af en applikation bygget på 4D-platformen (4. Dimension), den relationelle database og udviklingsmiljøet med lav kode, der oprindeligt blev udgivet af Laurent Ribardières team i 1984 og nu vedligeholdt af 4D SAS. I modsætning til en ren SQL-database samler 4D datamotoren, et programmeringssprog, en formulardesigner og en web/REST-server i ét produkt — så “arkitekturen” her spænder over både skemaet og applikationslagene, der sidder oven på det.

Begrebet forveksles nogle gange med arkitektonisk visualisering (4D BIM, tid som den fjerde dimension i bygningsdesign). Denne vejledning dækker softwareforstanden: hvordan man opretter en 4D-database og dens applikationslag. Hvis du ankom på udkig efter bygningsdesign, gælder nedenstående koncepter ikke.

De tre lag i en 4D-applikation

4D-arkitekturdesignprojekter drager fordel af en eksplicit lagdelt model. Opdeling af ansvar forhindrer en voksende app i at blive til et virvar af formularscripts.

Lag 1 — Datamodellen

Datamodellen er det sæt af tabeller, felter, relationer og indekser, der er gemt i 4D-strukturfilen. Dette lag bør ikke indeholde nogen brugergrænsefladekode og ingen forretningsregler, der kunne leve andre steder. Felttyper (tekst, heltal, reelt, dato, klokkeslæt, boolesk, blob, objekt, billede) og feltlængder er fastsat her, og at ændre dem senere i en live database kræver omhu.

Lag 2 — Forretningslogik

Forretningslogikken lever i projektmetoder, klasser og tabeltriggere. I moderne 4D giver klasser (introduceret med 4D v18 R3 og udvidet siden) dig mulighed for at skrive genbrugelig, testbar kode i stedet for at sprede logik på tværs af formularmetoder. En trigger på en tabel udløses ved oprettelse, lagring og sletning - nyttigt til revisionsspor, men en trigger, der kalder brugergrænsefladen, vil bryde i headless serverkontekster.

Relateret: — En regneark-simpel grænseflade, der sidder oven på en rigtig relationel database, med automatiseringer, visninger og delbare grænseflader..

Lag 3 — Præsentation

Præsentationen dækker formularer, listebokse, inputdialoger og enhver web- eller REST-output. 4D-formularer binder direkte til felter og variabler, hvilket er praktisk, men tilskynder til at lægge logik i formularen. At holde formmetoderne tynde - at kalde en klassemetode og vise resultatet - er den største enkeltvedligeholdelsesgevinst i de fleste 4D-projekter.

Design af datamodellen: tabeller, relationer og nøgler

Datamodelleringsbeslutninger i 4D-arkitekturdesign følger relationelle principper med 4D-specifik mekanik lagt på lag.

Valg af tabelgranularitet

En tabel skal repræsentere én enhedstype. At opdele en “kunde”-tabel i “kunde” og “kundeadresse” giver mening, når en kunde kan have flere adresser; sammenlægning af dem giver mening, når der er præcis én adresse pr. kunde og ingen genbrug. Overnormalisering i mange små tabeller øger antallet af relationer og joinforbindelser, hvilket koster ydeevne i listevisninger.

Hvis du handler: — En lavkode-appbygger, der tilsluttes den bredere Zoho-suite og priser pr. bruger i stedet for pr. app..

Relationstyper

4D understøtter automatiske relationer defineret i struktureditoren og manuelle relationer oprettet i kode. De almindelige mønstre:

Forhold	4D implementering	Typisk brug
En-til-mange	Fremmednøglefelt på “mange”-siden plus en relation	Faktura → Fakturalinjer
Mange-til-mange	Forbindelsestabel med to fremmednøgler	Produkter ↔ Leverandører
En-til-en	Delt primærnøgle eller en unik fremmednøgle	Bruger → Brugerprofil
Selvreference	Fremmednøgle, der peger tilbage til samme tabel	Medarbejder → Leder

Primær nøglestrategi

4D tilbyder auto-incrementing longint primære nøgler og UUID (tekst) primære nøgler. Longint-nøgler er kompakte og hurtige at indeksere; UUID’er er globalt unikke, hvilket betyder noget, når du flette data fra flere websteder eller synkronisere med eksterne systemer. Et almindeligt kompromis er en longint intern nøgle plus et separat unikt “ekstern reference” tekstfelt.

Indeksering og forespørgselsydelse

Indekser er den højeste løftestang for ydeevne i 4D-arkitekturdesign, og også den nemmeste at overanvende.

Hvad skal indekseres

Indekser ethvert felt, der bruges som en relations fremmednøgle, ethvert felt, der ofte bruges i en forespørgsels søgekriterier, og ethvert felt, der bruges til at sortere i store listebokse. 4D understøtter standard B-træindekser, nøgleordsindekser til ordbaseret tekstsøgning og sammensatte indekser, der dækker flere felter.

Hvad der ikke skal indekseres

Hvert indeks tilføjer skriveomkostninger og lagerplads. Indeksering af et boolesk felt med to mulige værdier hjælper sjældent. Indeksering af et felt, der kun læses som en del af en fuld-record-visning, tilføjer overhead uden gevinst. Gennemgå indekser, efter at applikationen har reelle brugsmønstre i stedet for at gætte på forhånd.

Forespørgselsstrategi

ORDA-forespørgsler (ds.Invoice.query("Status = :1"; "Åben")) er generelt at foretrække frem for klassiske QUERY-kommandoer til ny kode, fordi de returnerer entitetsvalg, der kan sorteres, filtreres og sendes mellem metoder uden at forespørge igen. For meget store tabeller vil begrænsning af forespørgslen med indekserede kriterier før anvendelse af ikke-indekserede filtre holde svartider forudsigelige.

Relateret: — En kodefri databasebygger rettet mod portaler, mapper og interne værktøjer - med faste priser i stedet for gebyrer pr. bruger..

ORDA og moderne 4D-arkitektur

ORDA (Object Relational Data Access) er 4D’s objektorienterede dataadgangslag, introduceret i 4D v17. Den eksponerer tabeller som dataklasser og poster som entiteter, så en tabel med navnet Invoice bliver til ds.Invoice og et felt ved navn TotalNet bliver til $invoice.TotalNet.

Dette har en arkitektonisk konsekvens for 4d-arkitekturdesign: tabel- og feltnavne er nu en del af din offentlige API. Omdøbning af et felt bryder kode på en måde, der er synlig på kompileringstidspunktet, men inkonsekvent navngivning gør ORDA-koden svær at læse. At vedtage en konvention - enkeltstående tabelnavne, PascalCase-felter, ingen forkortelser - betaler sig straks.

ORDA understøtter også entitetsvalg på klientsiden, der kun er delvist indlæst, hvilket ændrer ydeevneprofilen for listeskærme. En listeboks, der er bundet til en entitetsvalg, kan vise tusindvis af rækker uden at indlæse hver post, forudsat at forespørgslen bag den er indekseret.

Vores valg: — Den langvarige relationsdatabaseplatform til teams, der har brug for tilpassede apps på desktop, web og mobil fra en enkelt fil..

Client-Server, Single-User og Web Deployment

Implementeringstopologien former 4d-arkitekturdesignet mere end mange udviklere forventer.

Enkeltbruger-applikationer kører datamotoren og grænsefladen i én proces. Låsning er trivielt; justering af ydeevne handler for det meste om lokal diskhastighed.

Client-server opdeler 4D-serveren (datamotor) fra 4D-klient (grænseflade). Optegnelser er låst på serveren, og netværksomkostningerne for hver forespørgsel bliver betydelige. Arkitekturer, der udsender mange små forespørgsler pr. skærm, klarer sig dårligt her; batching forespørgsler og brug af entitetsvalg reducerer round-trips.

Web- og REST-implementering afslører den samme datamodel gennem 4D’s REST-server eller gennem kompilerede webmetoder. Sikkerhed rykker i forgrunden: tabel- og feltadgang skal begrænses gennem roller og privilegier, og enhver forretningsregel, der kun håndhæves i en formularmetode, håndhæves faktisk ikke for webklienter.

Navnekonventioner og dokumentation

Konsekvent navngivning er uglamorøst, men afgørende for 4d-arkitekturdesign. En brugbar konvention for 4D:

Tabeller: Ental substantiver, PascalCase (“Kunde”, “InvoiceLine”).
Felter: PascalCase, uden typepræfikser (“InvoiceDate”, ikke “dInvDate”).
Relationer: navngivet i henhold til destinationstabellen (“Customer_Invoices”).
Metoder: verbum først (“CreateInvoice”, “RecalculateTotals”).
Klasser: Navneord først (“InvoiceService”, “TaxCalculator”).

Dokumentation af skemaet - selv som en enkelt Markdown-fil, der viser hver tabel, dens formål og dens nøglerelationer - gør onboarding og fremtidige migreringer meget nemmere. 4D’s struktureditor viser relationer grafisk, men den forklarer ikke hvorfor en tabel eksisterer.

Almindelige 4D-arkitekturdesignfejl

Indsætte forretningslogik i formularmetoder. Formmetoder kan ikke kaldes fra webkontekster eller planlagte opgaver, så logik fanget der skal duplikeres.

Brug af valgbaserede klassiske kommandoer i hele ny kode. Klassiske selektioner er procesbundne og går ikke godt mellem processer; ORDA-entitetsvalg er mere fleksible.

Spring over krydstabellen. Lagring af flere værdier i et enkelt tekstfelt (kommaseparerede id’er) modvirker indeksering og gør rapportering smertefuldt.

Indeksering af alt. Skriveydelse forringes, og fordelen er sjældent realiseret.

Ignorerer privilegier indtil implementering. Det er betydeligt sværere at eftermontere en sikkerhedsmodel på en færdig applikation end at designe den sammen med skemaet.

Sådan beslutter du: En praktisk tjekliste

Før du bygger dit 4d-arkitekturdesign, skal du arbejde igennem disse spørgsmål:

Hvor mange samtidige brugere, og vil de oprette forbindelse over et LAN, WAN eller internettet?
Hvilke entiteter har en naturlig en-til-mange relation, og hvilke har brug for forbindelsestabeller?
Hvilke felter vises i søgekriterier eller sorteringsrækkefølger på store tabeller?
Hvilke forretningsregler skal holde uanset indgangspunkt (formular, web, import)?
Vil data nogensinde blive flettet sammen med et andet system, der kræver UUID-nøgler?
Hvem vedligeholder dette om to år, og vil navngivningen give mening for dem?

Svar på disse seks spørgsmål bestemmer de fleste af de strukturelle beslutninger i et 4D-projekt.

Yderligere læsning

Den officielle 4D-dokumentation på developer.4d.com dækker ORDA, klasser, privilegier og implementering i detaljer. For grundlæggende principper om relationel modellering, der gælder uanset platform, se Wikipedia-artiklen om databasenormalisering. For den bredere kontekst af platforme med lav kode og hurtig applikationsudvikling er Wikipedia-indlægget om udviklingsplatforme med lav kode et rimeligt udgangspunkt. 4D SAS udgiver også release notes og migrationsvejledninger, der beskriver, hvornår ORDA, klasser og andre 4d-arkitekturdesignfunktioner blev introduceret.

Ofte stillede spørgsmål

Hvad er 4D-arkitekturdesign?

4D-arkitekturdesign er processen med at planlægge strukturen af en 4D (4. dimension) applikation: dens tabeller, felter, relationer, indekser, forretningslogiklag og præsentationslag. Den bestemmer, hvordan applikationen fungerer, hvor let den kan ændres, og hvor sikker den kan implementeres på desktop, klient-server eller webklienter.

Er 4D-arkitektur det samme som 4D BIM?

Nej. 4D BIM tilføjer tid som en fjerde dimension til bygningsinformationsmodellering til byggeplanlægning. 4D-arkitektur i softwareforstand refererer til design af applikationer på 4D-databaseplatformen. De to felter deler en forkortelse, men intet andet.

Skal jeg bruge ORDA eller klassiske 4D-kommandoer?

ORDA er den bedste mulighed for nye udviklinger. Det returnerer entitetsvalg, der kan overføres mellem metoder, sorteres og filtreres uden at skulle forespørges igen, og viser tabeller og felter som egenskaber for læsbare objekter. Klassiske valgbaserede kommandoer er stadig nyttige i ældre kode og i nogle specielle tilfælde.

Hvor mange indekser skal en 4D-tabel have?

Der er ikke noget fast antal. Indeks fremmednøgler, felter brugt i almindelige søgekriterier og felter brugt til at sortere store lister. Undgå at indeksere felter med lav kardinalitet, såsom booleske værdier eller statusfelter med to eller tre værdier, da skriveomkostningerne normalt opvejer læsefordelen.

Hvilken primær nøgletype skal jeg vælge i 4D?

Auto-incrementing longint-nøgler er kompakte og hurtige og passer til enkelt-site applikationer. UUID-tekstnøgler er større, men globalt unikke, hvilket betyder noget, når du flette data fra flere websteder eller integrere med eksterne systemer. Mange projekter bruger en longint nøgle internt plus et unikt eksternt referencefelt.

Kan jeg ændre 4D-datamodellen efter implementering?

Ja, men med omhu. Tilføjelse af tabeller, felter og indekser er generelt ligetil. Ændring af felttyper, omdøbning af felter brugt af ORDA-kode eller omstrukturering af relationer på en live database kræver en planlagt migrering, ideelt set testet på en kopi af produktionsdata først.