4D-arkitekturdesign: En komplett guide

Av HPO Software Learning Desk · Uppdaterad 28 september 2026

4D-arkitektonisk design är processen att strukturera en 4D-databas (dess tabeller, fält, relationer, index och åtkomstnivåer) så att applikationen förblir snabb, underhållsbar och säker när den växer. Ett välplanerat 4D-schema involverar vanligtvis fem kärnbeslut: tabellgranularitet, relationsstrategi, primärnyckeltyp, indexplats och separation av data från gränssnittslogik. Att få det här rätt från början hjälper dig att undvika kostsamma migreringar i framtiden.

Viktiga punkter

4D-arkitekturdesign separerar tre ansvarsområden: datamodellen (tabeller, fält, relationer), affärslogikskiktet (metoder, klasser, utlösare) och presentationsskiktet (formulär, listrutor, dialogrutor).
Relationstyp är viktigare än tabellräkning: en många-till-många-länk behöver en kopplingstabell, medan en en-till-många-länk använder ett främmande nyckelfält plus en relation.
Index snabbar upp läsning men saktar ner skrivning - indexera främmande nycklar och alla fält som används i en frågas WHERE-sats, inte alla fält.
4D:s ORDA-lager (Object Relational Data Access) ändrar hur du tänker om schema: väl namngivna tabeller och fält blir läsbara dataklass- och attributnamn i kod.
Klient-server kontra enanvändardistribution är ett arkitektoniskt beslut, inte en eftertanke om distributionen – det påverkar låsning, cachelagring och hur du skriver frågor.
Namnkonventioner som tillämpas konsekvent från dag ett sparar mer tid för omstrukturering än någon annan enskild vana.

Vad “4D-arkitektur” betyder i en databaskontext

4D-arkitekturdesign hänvisar till den strukturella designen av en applikation byggd på 4D-plattformen (4:e dimensionen), den relationella databasen och utvecklingsmiljön med låg kod som ursprungligen släpptes av Laurent Ribardières team 1984 och nu underhålls av 4D SAS. Till skillnad från en ren SQL-databas, paketerar 4D datamotorn, ett programmeringsspråk, en formulärdesigner och en webb/REST-server till en produkt — så “arkitekturen” sträcker sig här över både schemat och applikationslagren som sitter ovanpå den.

Termen förväxlas ibland med arkitektonisk visualisering (4D BIM, tid som fjärde dimension i byggnadsdesign). Den här guiden täcker mjukvarans betydelse: hur man lägger ut en 4D-databas och dess applikationslager. Om du kom för att leta efter byggnadsdesign, kommer begreppen nedan inte att gälla.

De tre skikten i en 4D-applikation

4D-arkitekturdesignprojekt drar nytta av en explicit lagermodell. Att dela upp ansvar hindrar en växande app från att förvandlas till en härva av formulärskript.

Lager 1 — Datamodellen

Datamodellen är uppsättningen tabeller, fält, relationer och index som lagras i 4D-strukturfilen. Det här lagret bör inte innehålla någon användargränssnittskod och inga affärsregler som kan finnas någon annanstans. Fälttyper (text, heltal, verkligt, datum, tid, Boolean, blob, objekt, bild) och fältlängder är fixerade här, och att ändra dem senare i en livedatabas kräver försiktighet.

Lager 2 — Affärslogik

Affärslogik bor i projektmetoder, klasser och tabelltriggare. I modern 4D låter klasser (introducerade med 4D v18 R3 och utökade sedan) dig skriva återanvändbar, testbar kod istället för att sprida logik över formulärmetoder. En utlösare på en tabell aktiveras vid skapa, spara och ta bort — användbar för granskningsspår, men en utlösare som anropar användargränssnittet kommer att gå sönder i headless serverkontexter.

Relaterat: — Den långvariga relationsdatabasplattformen för team som behöver anpassade appar på skrivbordet, webben och mobilen från en enda fil..

Lager 3 — Presentation

Presentationen omfattar formulär, listrutor, inmatningsdialoger och alla webb- eller REST-utdata. 4D-formulär binder direkt till fält och variabler, vilket är bekvämt men uppmuntrar till att lägga in logik i formuläret. Att hålla formulärmetoderna tunna – anropa en klassmetod och visa resultatet – är den enskilt största underhållsvinsten i de flesta 4D-projekt.

Designa datamodellen: tabeller, relationer och nycklar

Datamodelleringsbeslut i 4D-arkitekturdesign följer relationsprinciper, med 4D-specifik mekanik på lager.

Välja tabellgranularitet

En tabell ska representera en enhetstyp. Att dela upp en “kund”-tabell i “kund” och “kundadress” är vettigt när en kund kan ha flera adresser; att slå ihop dem är vettigt när det finns exakt en adress per kund och ingen återanvändning. Övernormalisering i många små tabeller ökar antalet relationer och joins, vilket kostar prestanda i listvyer.

Vårt val: — Ett enkelt kalkylarksgränssnitt som sitter ovanpå en riktig relationsdatabas, med automatiseringar, vyer och delbara gränssnitt..

Relationstyper

4D stöder automatiska relationer definierade i strukturredigeraren och manuella relationer skapade i kod. De vanliga mönstren:

Förhållande	4D-implementering	Typisk användning
En-till-många	Fält för främmande nyckel på “många”-sidan plus en relation	Faktura → Fakturarader
Många-till-många	Kopplingstabell med två främmande nycklar	Produkter ↔ Leverantörer
En-till-en	Delad primärnyckel eller unik främmande nyckel	Användare → Användarprofil
Självrefererande	Främmande nyckel som pekar tillbaka till samma tabell	Anställd → Chef

Primär nyckelstrategi

4D erbjuder auto-incrementing longint primärnycklar och UUID (text) primärnycklar. Longint-nycklar är kompakta och snabba att indexera; UUID:er är globalt unika, vilket är viktigt när du slår samman data från flera webbplatser eller synkroniserar med externa system. En vanlig kompromiss är en longint intern nyckel plus ett separat unikt “extern referens” textfält.

Indexering och frågeprestanda

Index är den högsta hävstångsspaken för prestanda i 4D-arkitekturdesign, och även den enklaste att överanvända.

Vad ska indexeras

Indexera alla fält som används som en relations främmande nyckel, alla fält som ofta används i en frågas sökkriterier och alla fält som används för att sortera i stora listrutor. 4D stöder standard B-trädindex, nyckelordsindex för ordbaserad textsökning och sammansatta index som täcker flera fält.

Vad man inte ska indexera

Varje index lägger till skrivkostnad och lagring. Att indexera ett booleskt fält med två möjliga värden hjälper sällan. Att indexera ett fält som bara alltid läses som en del av en fullständig postvisning lägger till overhead utan vinst. Granska index efter att applikationen har riktiga användningsmönster snarare än att gissa i förväg.

Frågestrategi

ORDA-frågor (ds.Invoice.query("Status = :1"; "Öppen")) är i allmänhet att föredra framför klassiska QUERY-kommandon för ny kod eftersom de returnerar entitetsval som kan sorteras, filtreras och skickas mellan metoder utan att behöva göra en ny fråga. För mycket stora tabeller, begränsning av frågan med indexerade kriterier innan icke-indexerade filter tillämpas håller svarstiderna förutsägbara.

Relaterat: — En databasbyggare utan kod som syftar till portaler, kataloger och interna verktyg – med schablonpris i stället för avgifter per användare..

ORDA och modern 4D-arkitektur

ORDA (Object Relational Data Access) är 4D:s objektorienterade dataåtkomstlager, introducerat i 4D v17. Den exponerar tabeller som dataklasser och poster som entiteter, så en tabell som heter Invoice blir ds.Invoice och ett fält som heter TotalNet blir $invoice.TotalNet.

Detta har en arkitektonisk konsekvens för design av 4d-arkitektur: tabell- och fältnamn är nu en del av ditt offentliga API. Att byta namn på ett fält bryter kod på ett sätt som är synligt vid kompilering, men inkonsekvent namngivning gör ORDA-koden svår att läsa. Att anta en konvention – enstaka tabellnamn, PascalCase-fält, inga förkortningar – lönar sig direkt.

ORDA stöder även entitetsval på klientsidan som bara är delvis inlästa, vilket ändrar prestandaprofilen för listskärmar. En listruta bunden till en entitetsval kan visa tusentals rader utan att ladda varje post, förutsatt att frågan bakom den är indexerad.

Om du handlar: — En appbyggare med låg kod som ansluts till den bredare Zoho-sviten och priser per användare snarare än per app..

Client-Server, Single-User och Web Deployment

Distributionstopologin formar 4D-arkitekturen mer än vad många utvecklare förväntar sig.

Enanvändarapplikationer kör datamotorn och gränssnittet i en process. Låsning är trivialt; prestandajustering handlar mest om lokal diskhastighet.

Client-server delar upp 4D-servern (datamotor) från 4D-klienten (gränssnitt). Posterna är låsta på servern och nätverkskostnaden tur och retur för varje fråga blir betydande. Arkitekturer som ger många små frågor per skärm fungerar dåligt här; batchförfrågningar och användning av entitetsval minskar tur och retur.

Web- och REST-distribution exponerar samma datamodell genom 4D:s REST-server eller genom kompilerade webbmetoder. Säkerheten går i främsta rummet: tabell- och fältåtkomst måste begränsas genom roller och privilegier, och alla affärsregler som tillämpas endast i en formulärmetod tillämpas i praktiken inte för webbklienter.

Namnkonventioner och dokumentation

Konsekvent namngivning är oglamoröst men avgörande för 4D-arkitekturdesign. En fungerande konvention för 4D:

Tabeller: Singular substantiv, PascalCase (“Kund”, “InvoiceLine”).
Fält: PascalCase, utan typprefix (“InvoiceDate”, inte “dInvDate”).
Relationer: namnges enligt destinationstabellen (“Customer_Invoices”).
Metoder: verb först (“CreateInvoice”, “RecalculateTotals”).
Klasser: Substantiv först (“InvoiceService”, “TaxCalculator”).

Att dokumentera schemat – även som en enda Markdown-fil som listar varje tabell, dess syfte och dess nyckelrelationer – gör onboarding och framtida migrering mycket enklare. 4D:s strukturredigerare visar relationer grafiskt, men den förklarar inte varför en tabell existerar.

Vanliga 4D-arkitekturdesignmisstag

Inför affärslogik i formulärmetoder. Formulärmetoder kan inte anropas från webbkontexter eller schemalagda uppgifter, så logik som är instängd där måste dupliceras.

Använder urvalsbaserade klassiska kommandon genom hela ny kod. Klassiska urval är processbundna och går inte bra mellan processer; ORDA-enhetsvalen är mer flexibla.

Hoppa över kopplingstabellen. Att lagra flera värden i ett enda textfält (kommaseparerade ID:n) omöjliggör indexering och gör rapporteringen smärtsam.

Indexering av allt. Skrivprestanda försämras och fördelen är sällan realiserad.

Ignorera privilegier fram till distributionen. Att eftermontera en säkerhetsmodell på en färdig applikation är betydligt svårare än att designa den tillsammans med schemat.

Hur man bestämmer sig: En praktisk checklista

Innan du bygger din 4d-arkitekturdesign, arbeta igenom dessa frågor:

Hur många samtidiga användare, och kommer de att ansluta över ett LAN, WAN eller webben?
Vilka entiteter har en naturlig en-till-många-relation och vilka behöver korsningstabeller?
Vilka fält kommer att visas i sökkriterier eller sorteringsordningar på stora tabeller?
Vilka affärsregler måste gälla oavsett ingångspunkt (formulär, webb, import)?
Kommer data någonsin att slås samman med ett annat system som kräver UUID-nycklar?
Vem upprätthåller detta om två år, och kommer namnet att vara meningsfullt för dem?

Svar på dessa sex frågor avgör de flesta av de strukturella besluten i ett 4D-projekt.

Ytterligare läsning

Den officiella 4D-dokumentationen på developer.4d.com täcker ORDA, klasser, privilegier och distribution i detalj. För grunderna för relationsmodellering som gäller oavsett plattform, se Wikipedia-artikeln om databasnormalisering. För det bredare sammanhanget med plattformar med låg kod och snabb applikationsutveckling är Wikipedia-inlägget om utvecklingsplattformar med låg kod en rimlig utgångspunkt. 4D SAS publicerar också release notes och migrationsguider som beskriver när ORDA, klasser och andra designfunktioner för 4d-arkitektur introducerades.

Vanliga frågor

Vad är 4D-arkitekturdesign?

4D-arkitekturdesign är processen att planera strukturen för en 4D (4:e dimension) applikation: dess tabeller, fält, relationer, index, affärslogikskikt och presentationslager. Den bestämmer hur applikationen fungerar, hur lätt den kan ändras och hur säkert den kan distribueras till skrivbord, klient-server eller webbklienter.

Är 4D-arkitektur detsamma som 4D BIM?

Nej. 4D BIM lägger till tid som en fjärde dimension till byggnadsinformationsmodellering för byggplanering. 4D-arkitektur i mjukvarubemärkelse hänvisar till att designa applikationer på 4D-databasplattformen. De två fälten delar en förkortning men inget annat.

Ska jag använda ORDA eller klassiska 4D-kommandon?

ORDA är det bästa alternativet för nya utvecklingar. Den returnerar entitetsval som kan skickas mellan metoder, sorteras och filtreras utan att behöva frågas igen, och exponerar tabeller och fält som egenskaper för läsbara objekt. Klassiska urvalsbaserade kommandon är fortfarande användbara i äldre kod och i vissa speciella fall.

Hur många index bör en 4D-tabell ha?

Det finns inget fast nummer. Indexera främmande nycklar, fält som används i vanliga sökkriterier och fält som används för att sortera stora listor. Undvik att indexera fält med låg kardinalitet, såsom booleska värden eller statusfält med två eller tre värden, eftersom skrivkostnaden vanligtvis överväger läsfördelen.

Vilken typ av primärnyckel ska jag välja i 4D?

Auto-inkrementerande longint-nycklar är kompakta och snabba och passar applikationer på en plats. UUID-textnycklar är större men globalt unika, vilket är viktigt när du slår samman data från flera webbplatser eller integrerar med externa system. Många projekt använder en longint-nyckel internt plus ett unikt externt referensfält.

Kan jag ändra 4D-datamodellen efter implementeringen?

Ja, men med försiktighet. Att lägga till tabeller, fält och index är i allmänhet enkelt. Att ändra fälttyper, byta namn på fält som används av ORDA-kod eller omstrukturera relationer på en livedatabas kräver en planerad migrering, helst testad på en kopia av produktionsdata först.