4D-arkitekturdesign: En komplett guide

4D-arkitektonisk design er prosessen med å strukturere en 4D-database (dens tabeller, felt, relasjoner, indekser og tilgangsnivåer) slik at applikasjonen forblir rask, vedlikeholdbar og sikker mens den vokser. Et godt planlagt 4D-skjema involverer vanligvis fem kjernebeslutninger: tabellgranularitet, relasjonsstrategi, primærnøkkeltype, indeksplassering og separasjon av data fra grensesnittlogikk. Å få dette riktig fra begynnelsen vil hjelpe deg å unngå kostbare migreringer i fremtiden.

Viktige takeaways

• 4D-arkitekturdesign skiller mellom tre ansvarsområder: datamodellen (tabeller, felt, relasjoner), forretningslogikklaget (metoder, klasser, triggere) og presentasjonslaget (skjemaer, listebokser, dialoger).
• Relasjonstype betyr mer enn tabellantall: en mange-til-mange-kobling trenger en krysstabell, mens en en-til-mange-kobling bruker et fremmednøkkelfelt pluss en relasjon.
• Indekser gjør lesing raskere, men skriving tregere — indekser fremmednøkler og alle felt som brukes i en spørrings WHERE-klausul, ikke alle felt.
• 4Ds ORDA (Object Relational Data Access)-lag endrer hvordan du tenker om skjemaet: velnavngitte tabeller og felt blir lesbare dataklasser og attributtnavn i koden.
• Klient-server versus enkeltbruker-distribusjon er en arkitektonisk beslutning, ikke en ettertanke ved distribusjon — det påvirker låsing, hurtigbufring og hvordan du skriver spørringer.
• Navnekonvensjoner brukt konsekvent fra dag én sparer mer refaktoriseringstid enn noen annen enkeltvane.

Hva “4D-arkitektur” betyr i en databasekontekst

4D-arkitekturdesign refererer til den strukturelle utformingen av en applikasjon bygget på 4D-plattformen (4th Dimension), relasjonsdatabasen og lavkode-utviklingsmiljøet som opprinnelig ble utgitt av Laurent Ribardières team i 1984 og nå vedlikeholdes av 4D SAS. I motsetning til en ren SQL-database, samler 4D datamotoren, et programmeringsspråk, en skjemadesigner og en web/REST-server i ett produkt – så “arkitektur” her spenner over både skjemaet og applikasjonslagene som ligger på toppen av det.

Begrepet forveksles noen ganger med arkitektonisk visualisering (4D BIM, tid som fjerde dimensjon i bygningsdesign). Denne veiledningen dekker programvarebetydningen: hvordan man legger opp en 4D-database og dens applikasjonslag. Hvis du kom hit på jakt etter bygningsdesign, vil ikke konseptene nedenfor gjelde.

De tre lagene i en 4D-applikasjon

4D-arkitekturdesignprosjekter drar nytte av en eksplisitt lagdelt modell. Å dele ansvar hindrer en voksende app fra å bli et virvar av skjemaskript.

Lag 1 — Datamodellen

Datamodellen er settet med tabeller, felt, relasjoner og indekser lagret i 4D-strukturfilen. Dette laget skal ikke inneholde brukergrensesnittkode eller forretningsregler som kan ligge andre steder. Felttyper (tekst, heltall, reell, dato, klokkeslett, boolsk, blob, objekt, bilde) og feltlengder er faste her, og å endre dem senere i en aktiv database krever forsiktighet.

Lag 2 — Forretningslogikk

Forretningslogikk ligger i prosjektmetoder, klasser og tabelltriggere. I moderne 4D lar klasser (introdusert med 4D v18 R3 og utvidet siden) deg skrive gjenbrukbar, testbar kode i stedet for å spre logikk på tvers av skjemametoder. En trigger på en tabell utløses ved opprettelse, lagring og sletting – nyttig for revisjonsspor, men en trigger som kaller brukergrensesnittet vil feile i hodeløse serverkontekster.

Relatert: Claris FileMaker Pro — Den langvarige relasjonsdatabaseplattformen for team som trenger tilpassede apper på skrivebord, nett og mobil fra én enkelt fil..

Lag 3 — Presentasjon

Presentasjonen dekker skjemaer, listebokser, inndatadialoger og enhver web- eller REST-utgang. 4D-skjemaer bindes direkte til felt og variabler, noe som er praktisk, men oppmuntrer til å legge logikk i skjemaet. Å holde skjemametodene tynne – ved å kalle en klassemetode og vise resultatet – er den største enkeltgevinsten for vedlikehold i de fleste 4D-prosjekter.

Utforme datamodellen: tabeller, relasjoner og nøkler

Beslutninger om datamodellering i 4D-arkitekturdesign følger relasjonsprinsipper, med 4D-spesifikk mekanikk lagt på toppen.

Velge tabellgranularitet

En tabell bør representere én enhetstype. Å dele opp en “kunde”-tabell i “kunde” og “kundeadresse” er fornuftig når en kunde kan ha flere adresser; å slå dem sammen er fornuftig når det er nøyaktig én adresse per kunde og ingen gjenbruk. Overnormalisering til mange små tabeller øker antallet relasjoner og sammenføyninger (joins), noe som går ut over ytelsen i listevisninger.

Vårt valg: Airtable — Et regneark-enkelt grensesnitt som sitter på toppen av en ekte relasjonsdatabase, med automatiseringer, visninger og delbare grensesnitt..

Relasjonstyper

4D støtter automatiske relasjoner definert i struktureditoren og manuelle relasjoner opprettet i kode. Vanlige mønstre:

Relasjon	4D-implementering	Typisk bruk
En-til-mange	Fremmednøkkelfelt på “mange”-siden pluss en relasjon	Faktura → Fakturalinjer
Mange-til-mange	Krysstabell med to fremmednøkler	Produkter ↔ Leverandører
En-til-en	Delt primærnøkkel eller en unik fremmednøkkel	Bruker → Brukerprofil
Selvrefererende	Fremmednøkkel som peker tilbake til samme tabell	Ansatt → Leder

Primærnøkkelstrategi

4D tilbyr auto-inkrementerende longint-primærnøkler og UUID (tekst)-primærnøkler. Longint-nøkler er kompakte og raske å indeksere; UUID-er er globalt unike, noe som er viktig når man slår sammen data fra flere lokasjoner eller synkroniserer med eksterne systemer. Et vanlig kompromiss er en intern longint-nøkkel pluss et eget unikt tekstfelt for “ekstern referanse”.

Indeksering og spørringsytelse

Indekser er det kraftigste verktøyet for ytelse i 4D-arkitekturdesign, og også det som er lettest å overbruke.

Hva skal indekseres

Indekser ethvert felt som brukes som en relasjons fremmednøkkel, ethvert felt som ofte brukes i søkekriteriene i en spørring, og alle felt som brukes til sortering i store listebokser. 4D støtter standard B-tre-indekser, nøkkelordindekser for ordbasert tekstsøk og sammensatte indekser som dekker flere felt.

Hva du ikke skal indeksere

Hver indeks øker skrivekostnaden og lagringsbehovet. Å indeksere et boolsk felt med to mulige verdier hjelper sjelden. Indeksering av et felt som bare leses som en del av en fullstendig postvisning, gir overhead uten gevinst. Gjennomgå indekser etter at applikasjonen har reelle bruksmønstre i stedet for å gjette på forhånd.

Spørringsstrategi

ORDA-spørringer (ds.Invoice.query("Status = :1"; "Open")) er generelt å foretrekke fremfor klassiske QUERY-kommandoer for ny kode, fordi de returnerer enhetsutvalg som kan sorteres, filtreres og sendes mellom metoder uten å måtte spørre på nytt. For svært store tabeller vil det å begrense spørringen med indekserte kriterier før man bruker ikke-indekserte filtre holde responstiden forutsigbar.

Relatert: Knack — En databasebygger uten kode rettet mot portaler, kataloger og interne verktøy – med fastpris i stedet for avgifter per bruker..

ORDA og moderne 4D-arkitektur

ORDA (Object Relational Data Access) er 4Ds objektorienterte datatilgangslag, introdusert i 4D v17. Det eksponerer tabeller som dataklasser og poster som entiteter, slik at en tabell som heter Invoice blir ds.Invoice og et felt kalt TotalNet blir $invoice.TotalNet.

Dette har en arkitektonisk konsekvens for 4D-arkitekturdesign: tabell- og feltnavn er nå en del av ditt offentlige API. Å gi nytt navn til et felt bryter koden på en måte som er synlig ved kompilering, men inkonsekvent navngiving gjør ORDA-kode vanskelig å lese. Å vedta en konvensjon – entall for tabellnavn, PascalCase for felt, ingen forkortelser – lønner seg umiddelbart.

ORDA støtter også enhetsutvalg på klientsiden som bare er delvis lastet, noe som endrer ytelsesprofilen til listeskjermer. En listeboks bundet til et enhetsutvalg kan vise tusenvis av rader uten å laste hver post, forutsatt at spørringen bak den er indeksert.

Hvis du handler: Zoho Creator — En lavkode-appbygger som kobles til den bredere Zoho-pakken og priser per bruker i stedet for per app..

Klient-server, enkeltbruker og web-distribusjon

Distribusjonstopologien former 4D-arkitekturdesignet mer enn mange utviklere forventer.

Enkeltbruker-applikasjoner kjører datamotoren og grensesnittet i én prosess. Låsing er trivielt; ytelsesoptimalisering handler for det meste om lokal diskhastighet.

Klient-server skiller 4D Server (datamotor) fra 4D Client (grensesnitt). Poster låses på serveren, og nettverkets tur-retur-kostnad for hver spørring blir betydelig. Arkitekturer som sender mange små spørringer per skjerm fungerer dårlig her; batching av spørringer og bruk av enhetsutvalg reduserer antall turer over nettverket.

Web- og REST-distribusjon eksponerer den samme datamodellen gjennom 4Ds REST-server eller gjennom kompilerte webmetoder. Sikkerhet kommer i forgrunnen: tabell- og felttilgang må begrenses gjennom roller og privilegier, og enhver forretningsregel som kun håndheves i en skjemametode, er i praksis ikke håndhevet for webklienter.

Navnekonvensjoner og dokumentasjon

Konsekvent navngiving er lite glamorøst, men avgjørende for 4D-arkitekturdesign. En brukbar konvensjon for 4D:

• Tabeller: Entallssubstantiv, PascalCase (“Customer”, “InvoiceLine”).
• Felt: PascalCase, uten typeprefikser (“InvoiceDate”, ikke “dInvDate”).
• Relasjoner: navngitt etter destinasjonstabellen (“Customer_Invoices”).
• Metoder: verb først (“CreateInvoice”, “RecalculateTotals”).
• Klasser: Substantiv først (“InvoiceService”, “TaxCalculator”).

Dokumentasjon av skjemaet – selv som en enkelt Markdown-fil som lister opp hver tabell, dens formål og dens nøkkelrelasjoner – gjør onboarding og fremtidige migreringer mye enklere. 4Ds struktureditor viser relasjoner grafisk, men den forklarer ikke hvorfor en tabell eksisterer.

Vanlige 4D-arkitekturdesignfeil

Å legge forretningslogikk i skjememetoder. Skjememetoder kan ikke kalles fra webkontekster eller planlagte oppgaver, så logikk som er fanget der, må dupliseres.

Bruk av utvalgsbaserte klassiske kommandoer i ny kode. Klassiske utvalg er prosessbundne og fungerer ikke godt mellom prosesser; ORDA-enhetsutvalg er mer fleksible.

Å hoppe over krysstabellen. Lagring av flere verdier i ett enkelt tekstfelt (kommaseparerte ID-er) ødelegger indeksering og gjør rapportering smertefullt.

Indeksering av alt. Skriveytelsen forringes, og gevinsten blir sjelden realisert.

Å ignorere privilegier frem til distribusjon. Å ettermontere en sikkerhetsmodell på en ferdig applikasjon er betydelig vanskeligere enn å designe den sammen med skjemaet.

Hvordan bestemme: En praktisk sjekkliste

Før du bygger ditt 4D-arkitekturdesign, gå gjennom disse spørsmålene:

1. Hvor mange samtidige brukere, og vil de koble seg til over LAN, WAN eller web?
2. Hvilke enheter har en naturlig en-til-mange-relasjon, og hvilke trenger krysstabeller?
3. Hvilke felt vil vises i søkekriterier eller sorteringsrekkefølger på store tabeller?
4. Hvilke forretningsregler må gjelde uavhengig av inngangspunkt (skjema, web, import)?
5. Vil data noen gang bli slått sammen med et annet system, noe som krever UUID-nøkler?
6. Hvem vedlikeholder dette om to år, og vil navngivingen gi mening for dem?

Svarene på disse seks spørsmålene bestemmer de fleste av de strukturelle beslutningene i et 4D-prosjekt.

Videre lesing

Den offisielle 4D-dokumentasjonen på developer.4d.com dekker ORDA, klasser, privilegier og distribusjon i detalj. For grunnleggende relasjonsmodellering som gjelder uavhengig av plattform, se Wikipedia-artikkelen om databasenormalisering.

For den bredere konteksten av lavkode- og plattformer for rask applikasjonsutvikling, er Wikipedia-oppføringen om lavkode-utviklingsplattformer et rimelig utgangspunkt. 4D SAS publiserer også utgivelsesnotater og migreringsveiledninger som beskriver når ORDA, klasser og andre 4D-arkitekturdesignfunksjoner ble introdusert.

Vanlige spørsmål

Hva er 4D-arkitekturdesign?

4D-arkitekturdesign er prosessen med å planlegge strukturen til en 4D (4th Dimension) applikasjon: dens tabeller, felt, relasjoner, indekser, forretningslogikklag og presentasjonslag. Det bestemmer hvordan applikasjonen yter, hvor enkelt den kan endres, og hvor sikkert den kan distribueres til skrivebord, klient-server eller webklienter.

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

Nei. 4D BIM legger til tid som en fjerde dimensjon i bygningsinformasjonsmodellering for byggeplanlegging. 4D-arkitektur i programvareforstand refererer til design av applikasjoner på 4D-databaseplattformen. De to feltene deler en forkortelse, men ingenting annet.

Bør jeg bruke ORDA eller klassiske 4D-kommandoer?

ORDA er det beste alternativet for nyutvikling. Det returnerer enhetsutvalg som kan sendes mellom metoder, sorteres og filtreres uten å måtte spørres på nytt, og eksponerer tabeller og felt som egenskaper ved lesbare objekter. Klassiske utvalgsbaserte kommandoer er fortsatt nyttige i eldre kode og i noen spesialtilfeller.

Hvor mange indekser bør en 4D-tabell ha?

Det finnes ikke noe fast antall. Indekser fremmednøkler, felt som brukes i vanlige søkekriterier, og felt som brukes til å sortere store lister. Unngå å indeksere felt med lav kardinalitet, som boolske verdier eller statusfelt med to eller tre verdier, da skrivekostnaden vanligvis oppveier lesefordelen.

Hvilken primærnøkkeltype bør jeg velge i 4D?

Auto-inkrementerende longint-nøkler er kompakte og raske, og passer for applikasjoner på ett enkelt sted. UUID-tekstnøkler er større, men globalt unike, noe som er viktig når man slår sammen data fra flere lokasjoner eller integrerer med eksterne systemer. Mange prosjekter bruker en longint-nøkkel internt pluss et unikt eksternt referansefelt.

Kan jeg endre 4D-datamodellen etter distribusjon?

Ja, men med forsiktighet. Å legge til tabeller, felt og indekser er generelt enkelt. Å endre felttyper, gi nytt navn til felt som brukes av ORDA-kode eller restrukturere relasjoner på en aktiv database krever en planlagt migrering, ideelt sett testet på en kopi av produksjonsdata først.