Grunnleggende om 4th Dimension Learning

4D-plattformen – opprinnelig 4th Dimension, og fortsatt viden kjent under sitt historiske navn – lagrer en hel applikasjons data i en enkelt strukturert datafil. Å forstå hvordan tabeller passer inn i denne arkitekturen er grunnlaget for alt annet du skal bygge: felt, skjemaer, verdilister og til slutt spørringene og metodene som driver en ekte forretningsapp. Denne delen går gjennom hvordan du lager din første tabell, åpner egenskapene og navngir den riktig, samtidig som begrunnelsen bak hvert trinn forklares slik at du trygt kan bruke det på større design.

Viktige takeaways

• I 4D lever alle tabeller i én datafil i stedet for i separate filer slik de gjør i FileMaker Pro (FMP). Denne enkeltfilmodellen er sentral for hvordan 4D håndterer sikkerhetskopiering, distribusjon og flerbrukertilgang.
• En 4D-database støtter opptil 256 tabeller, hver med maksimalt 2 GB data eller omtrent 16 millioner poster.
• Du lager tabeller fra Struktur-menyen mens du er i Designmodus.
• For å åpne egenskapene til en tabell, må du dobbeltklikke spesifikt på tabellnavnområdet – å klikke andre steder i strukturvinduet vil ikke åpne egenskapsdialogen.
• Vinduet Tabellegenskaper har tre faner; standardinnstillingene er trygge for et første prosjekt, og tabellnavnet kan endres når som helst.
• Navnekonvensjoner betyr noe: velg klare navn som er konsekvente i entall eller flertall, som “Kunder”, før du bygger skjemaer og relasjoner på toppen av dem.

Hvorfor tabeller er viktige i 4D-datamodellen

Hvis du kommer fra en FileMaker Pro-bakgrunn, er det mentale skiftet viktig. I FMP har hver tabell historisk levd i sin egen fil, og relasjoner ble administrert på tvers av filer. I 4D er arkitekturen annerledes: alle tabeller er lagret i den enkelte datafilen. Strukturen (designet ditt – tabeller, felt, skjemaer, metoder) holdes atskilt fra dataene (de faktiske postene brukerne legger inn), men hver tabell du definerer, lever i den ene datafilen.

Dette designet har praktiske konsekvenser som former hvordan du jobber:

• Sikkerhetskopiering er enklere. Fordi dataene er sentralisert, sikkerhetskopierer du én datafil i stedet for å spore mange.
• Distribusjon er renere. Du leverer en struktur og en datafil, ikke en mappe full av gjensidig avhengige dokumenter.
• Flerbrukertilgang er innebygd. 4D Server administrerer samtidig tilgang til den enkelte datafilen, slik at du ikke trenger å konstruere egne ordninger for fillåsing.

Avveiningen er at datafilen blir det eneste vekstpunktet. Det er nettopp derfor 4D pålegger grenser per tabell – opptil 256 tabeller, hver begrenset til 2 GB eller omtrent 16 millioner poster. For de fleste bedriftsapper for små team og avdelinger er disse takene generøse. Men hvis du designer noe som vil akkumulere millioner av transaksjonsrader, bør du tenke tidlig på hvordan du fordeler data på tvers av tabeller og om du trenger å arkivere eldre poster.

Lage en tabell trinn for trinn

For denne gjennomgangen vil vi lage bare én tabell, noe som gjør eksempeldatabasen enkel å følge. Den samme prosedyren kan skaleres til mange tabeller.

1. Gå inn i designmodus. Tabelloppretting er en strukturell endring, så du må være i designmodus. Du kan ikke legge til tabeller mens du kjører applikasjonen i brukermodus.
2. Åpne Struktur-menyen. Fra menylinjen velger du Struktur-menyen.
3. Velg “Ny tabell”. Dette menyelementet legger til en ny, tom tabell i strukturen din.
4. Finn den nye tabellen i strukturvinduet. Vinduet Structure for Sample Database (Figur 6 i den opprinnelige gjennomgangen) viser tabellene dine. En nyopprettet tabell vises som en navnløs oppføring.
5. Dobbeltklikk på tabellnavnområdet. Dette åpner vinduet Tabellegenskaper (Figur 7).

Det siste trinnet har en advarsel som er verdt å gjenta, fordi den ofte forvirrer nybegynnere: du må klikke på tabellnavnområdet og ikke andre steder. Strukturvinduet inneholder flere regioner, og bare navneområdet svarer ved å åpne dialogboksen Tabellegenskaper. Hvis ingenting skjer når du dobbeltklikker, klikker du nesten helt sikkert på feil sted – flytt markøren direkte over tabellens navn og prøv igjen.

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

Forstå vinduet Tabellegenskaper

Når vinduet Tabellegenskaper åpnes, vil du se tre faner. Den opprinnelige veiledningen er å la dem stå på standardverdiene foreløpig, og det er et godt råd for et første prosjekt – men det hjelper å vite hva du utsetter.

• Tabellnavn-feltet forblir synlig på hver fane. Dette er et bevisst designvalg: uansett hvilken fane du ser på, kan du gi tabellen et nytt navn. Du kan endre navnet når som helst, så et navn er aldri permanent.
• De andre fanene kontrollerer strukturell atferd – ting som hvordan tabellen inngår i den bredere databasen og hvordan postene administreres. For et eksempel med én tabell er det ingen av disse som trenger justering.

Den viktige vanen å bygge her er tilbakeholdenhet. Nye utviklere åpner ofte en egenskapsdialog og begynner å endre alternativer før de forstår hva hver enkelt gjør. I 4D, som i de fleste relasjonsdatabasedesign, er den sikreste veien å godta standardinnstillingene, få en fungerende tabell, og gå tilbake til avanserte innstillinger først når et konkret krav tvinger deg til det.

En merknad om navngivning

For eksempeldatabasen, navngi den første tabellen “Kunder”. Dette er en liten avgjørelse med store ringvirkninger videre:

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

• Vær konsekvent med flertall. Hvis du kaller denne tabellen “Kunder”, kall den neste “Bestillinger” og “Produkter” – ikke “Bestilling” og “Produkt”. Konsistens gjør relasjoner og kode mye lettere å lese.
• Unngå mellomrom og spesialtegn der du kan, siden tabellnavn ofte vises i kode og i genererte spørringer.
• Navngi etter enheten, ikke skjermen. “Kunder” beskriver en ting; “CustomerEntryScreen” beskriver et skjema. Hold disse konseptene atskilt.

Når du har skrevet inn navnet, klikker du på Bruk, og lukker deretter vinduet ved å bruke boksen øverst til venstre eller Ferdig-knappen. Tabellen din eksisterer nå i strukturen og er klar til å motta felt.

Hvordan tabeller passer med resten av databasen

En tabell er bare beholderen. Resten av applikasjonen din bygges på toppen av den i en klar sekvens, og det er verdt å se hele bildet før du fortsetter:

• Datafelt definerer kolonnene – de faktiske attributtene du lagrer, som for eksempel en kundes navn, adresse eller kontonummer.
• Skjemaer er brukergrensesnittet: skjermene der folk viser og redigerer poster.
• Verdilister (valglister) begrenser og øker hastigheten på dataregistrering ved å tilby forhåndsdefinerte alternativer.
• Eksempeldata lar deg teste skjemaer og lister med realistisk innhold før du går live.

Hver av disse avhenger av at tabellen eksisterer først. Dette er grunnen til at 4Ds designarbeidsflyt er bevisst ordnet: struktur før grensesnitt, grensesnitt før data. Hvis du prøver å bygge et skjema før de underliggende feltene eksisterer, vil du rett og slett ikke ha noe å binde dem til.

Det forklarer også hvorfor modellen med én enkelt datafil betyr så mye. Fordi hver tabell, hvert felt og hver post lever i én koordinert struktur, kan 4D håndheve relasjoner og referanseintegritet på tvers av hele applikasjonen uten at du trenger å administrere eksterne filer.

Dette er det samme prinsippet som ligger bak relasjonsdatabaseadministrasjonssystemer generelt – konseptet som ble formalisert i E. F. Codds relasjonsmodell og som nå er standard i produkter som Oracle Database, Microsoft SQL Server og PostgreSQL. 4D anvender denne relasjonelle tenkningen inne i en selvstendig applikasjonsfil, noe som gjør den tilgjengelig for små team og «citizen developers».

Praktisk veiledning for skalering utover én tabell

Eksemplet bruker en enkelt tabell for klarhetens skyld, men ekte apper stopper sjelden der. Når du legger til tabeller, bør du ha disse kriteriene i bakhodet:

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

Betraktning	Hva du bør sjekke	Hvorfor det er viktig
Tabellantall	Hold deg godt under grensen på 256 tabeller	Gir takhøyde og holder strukturen navigerbar
Størrelse per tabell	Pass på taket på 2 GB / ~16 millioner poster	Store transaksjonstabeller kan kreve arkivering eller oppsplitting
Navngivning	Konsekvent, enhetsbasert, ingen løse tegn	Påvirker kodelesbarhet og relasjonsklarhet
Relasjoner	Definer koblinger mellom tabeller bevisst	Forhindrer foreldreløse eller dupliserte data
Vekstplan	Bestem tidlig hva som skal arkiveres	Beskytter ytelsen etter hvert som data akkumuleres

En nyttig tommelfingerregel: modeller én tabell per enhet i den virkelige verden (kunder, bestillinger, produkter, fakturaer), og koble dem deretter sammen med relasjoner i stedet for å presse alt inn i én bred tabell. Dette gjenspeiler normaliseringsprinsippene som læres i de fleste databasekurs og holder 4D-strukturen din vedlikeholdbar etter hvert som appen vokser.

Vanlige feil å unngå

• Å klikke på feil område i strukturvinduet. Bare området for tabellnavn åpner Tabellegenskaper. Dette er den vanligste snublesteinen i dette trinnet.
• Å gi tabeller nytt navn sent uten å sjekke avhengigheter. Du kan endre navn når som helst, men hvis skjemaer, metoder eller relasjoner allerede refererer til det gamle navnet, må du oppdatere dem.
• Å ignorere størrelsesgrensene til det er for sent. Taket på 2 GB / 16 millioner poster per tabell er raust, men begrenset. Planlegg arkivering for tabeller med høyt volum.
• Å bygge skjemaer før felt. Arbeidsflytrekkefølgen eksisterer av en grunn – definer strukturen først.
• Over-tilpasning av egenskaper fra dag én. Standardinnstillingene er der for å hjelpe deg i gang. Endre dem når et krav krever det, ikke før.

Ofte stilte spørsmål

Hvor mange tabeller kan en 4D-database inneholde?

En 4D-database støtter opptil 256 tabeller. Hver tabell kan inneholde maksimalt 2 GB data, eller omtrent 16 millioner poster. For de fleste avdelings- og småteam-applikasjoner er disse grensene mer enn tilstrekkelige, men design med høyt volum bør planlegge for arkivering.

Hvorfor kan jeg ikke åpne vinduet for Tabellegenskaper?

Du klikker nesten helt sikkert på feil del av strukturvinduet. Dialogboksen for Tabellegenskaper åpnes bare når du dobbeltklikker direkte på området for tabellnavn. Å klikke andre steder i vinduet gjør ingenting, så flytt markøren til tabellens navn og prøv igjen.

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

Kan jeg gi en tabell nytt navn etter at den er opprettet?

Ja. Feltet for tabellnavn er synlig på alle tre fanene i vinduet for Tabellegenskaper, slik at du kan endre navnet når som helst. Husk bare at hvis skjemaer, metoder eller relasjoner allerede refererer til det gamle navnet, må du oppdatere disse referansene.

Må jeg endre på noen av fanene for Tabellegenskaper?

Ikke for et første prosjekt. Den opprinnelige gjennomgangen anbefaler å la standardinnstillingene være, og det er god praksis. De tre fanene kontrollerer strukturell atferd som du ikke vil ha behov for før et spesifikt krav tvinger deg til å gå tilbake til dem.

Hvordan er en 4D-tabell forskjellig fra en FileMaker Pro-fil?

I FileMaker Pro har tabeller historisk sett ligget i separate filer. I 4D er alle tabeller lagret i én enkelt datafil, noe som sentraliserer sikkerhetskopiering, distribusjon og flerbrukertilgang. Dette er den viktigste arkitektoniske forskjellen å sette seg inn i når man flytter mellom de to plattformene.

Hva skal jeg kalle min første tabell?

For eksempeldatabasen, gi den navnet “Customers.” Mer generelt bør du velge enhetsbaserte navn, holde flertallsformen konsistent på tvers av tabeller, og unngå mellomrom eller spesialtegn siden tabellnavn ofte vises i kode og genererte spørringer.

Veien videre

Nå som din første tabell er opprettet og navngitt, har du beholderen applikasjonen din trenger. Det neste trinnet er å definere datafelt — kolonnene som gir tabellen substans.

Derfra vil du bygge skjemaer for grensesnittet, koble opp verdilister for å øke hastigheten på dataregistrering, og til slutt legge inn eksempeldata for å teste alt fra ende til annen. Hvert trinn bygger direkte på tabellen du nettopp opprettet, så ta deg et øyeblikk til å bekrefte at den vises riktig i strukturvinduet før du går videre.