4th Dimension Learning – Grundlæggende principper

4D-platformen – oprindeligt 4th Dimension, og stadig bredt kendt under sit historiske navn – gemmer en hel applikations data i en enkelt struktureret datafil. At forstå, hvordan tabeller passer ind i den arkitektur, er grundlaget for alt det andet, du vil bygge: felter, formularer, værdilister og i sidste ende de forespørgsler og metoder, der driver en rigtig virksomhedsapp. Dette afsnit gennemgår oprettelsen af din første tabel, åbning af dens egenskaber og korrekt navngivning, mens ræsonnementet bag hvert trin forklares, så du trygt kan anvende det på større designs.

Key Takeaways

• I 4D lever alle tabeller i én datafil i stedet for i separate filer, som de gør i FileMaker Pro (FMP). Denne enkeltfilsmodel er central for, hvordan 4D håndterer backup, implementering og adgang for flere brugere.
• En 4D-database understøtter op til 256 tabeller, hver med et maksimum på 2 GB data eller omkring 16 millioner poster.
• Du opretter tabeller fra menuen Struktur, mens du er i Designtilstand.
• For at åbne en tabels egenskaber skal du specifikt dobbeltklikke på tabelnavneområdet – at klikke andre steder i strukturvinduet vil ikke åbne egenskabsdialogen.
• Vinduet Tabelegenskaber har tre faner; standardindstillingerne er sikre for et første projekt, og tabelnavnet kan ændres til enhver tid.
• Navnekonventioner betyder noget: Vælg klare navne, der er konsekvente i ental eller flertal, som f.eks. “Kunder”, før du bygger formularer og relationer oven på dem.

Hvorfor tabeller betyder noget i 4D-datamodellen

Hvis du kommer fra en FileMaker Pro-baggrund, er det mentale skift vigtigt. I FMP levede hver tabel historisk i sin egen fil, og relationer blev administreret på tværs af filer. I 4D er arkitekturen anderledes: alle tabeller er gemt i den enkelte datafil. Strukturen (dit design – tabeller, felter, formularer, metoder) holdes adskilt fra dataene (de faktiske poster, som brugerne indtaster), men hver tabel, du definerer, findes i den ene datafil.

Dette design har praktiske konsekvenser, der former, hvordan du arbejder:

• Backups er enklere. Fordi dataene er centraliserede, tager du backup af én datafil i stedet for at holde styr på mange.
• Implementeringen er renere. Du leverer en struktur og en datafil, ikke en mappe fuld af indbyrdes afhængige dokumenter.
• Multibrugeradgang er indbygget. 4D Server administrerer samtidig adgang til den enkelte datafil, så du ikke selv behøver at udvikle systemer til fillåsning.

Afvejningen er, at datafilen bliver det eneste vækstpunkt. Det er præcis grunden til, at 4D pålægger grænser pr. tabel – op til 256 tabeller, hver begrænset til 2 GB eller omkring 16 millioner poster. For de fleste små teams og afdelingsspecifikke virksomhedsapps er disse lofter generøse. Men hvis du designer noget, der vil akkumulere millioner af transaktionsrækker, bør du tidligt tænke over, hvordan du fordeler data på tværs af tabeller, og om du skal arkivere ældre poster.

Oprettelse af en tabel trin for trin

Til denne gennemgang vil vi kun oprette én tabel, hvilket gør prøvedatabasen nem at følge. Den samme procedure kan skaleres til mange tabeller.

1. Gå ind i designtilstand. Oprettelse af tabeller er en strukturel ændring, så du skal være i designtilstand. Du kan ikke tilføje tabeller, mens du kører applikationen i brugertilstand.
2. Åbn menuen Struktur. Fra menulinjen skal du vælge menuen Struktur.
3. Vælg “Ny tabel”. Dette menupunkt tilføjer en ny, tom tabel til din struktur.
4. Find den nye tabel i strukturvinduet. Vinduet Struktur for prøvedatabase (Figur 6 i den originale gennemgang) viser dine tabeller. En nyoprettet tabel vises som en unavngiven post.
5. Dobbeltklik på tabelnavneområdet. Dette åbner vinduet Tabelegenskaber (Figur 7).

Det sidste trin indeholder en advarsel, der er værd at gentage, fordi den ofte snyder nybegyndere: du skal klikke på tabelnavneområdet og ikke andre steder. Strukturvinduet indeholder flere områder, og kun navneområdet reagerer ved at åbne dialogboksen Tabelegenskaber. Hvis der ikke sker noget, når du dobbeltklikker, klikker du næsten helt sikkert det forkerte sted – flyt markøren direkte hen over tabellens navn og prøv igen.

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

Forstå vinduet med tabelegenskaber

Når vinduet Tabelegenskaber åbnes, vil du se tre faner. Den oprindelige vejledning er at lade dem stå på deres standardindstillinger for nu, og det er et godt råd til et første projekt – men det hjælper at vide, hvad du udskyder.

• Feltet Tabelnavn forbliver synligt på hver fane. Dette er et bevidst designvalg: uanset hvilken fane du ser, kan du omdøbe tabellen. Du kan ændre navnet til enhver tid, så et navn er aldrig permanent.
• De andre faner styrer strukturel adfærd – ting som hvordan tabellen indgår i den bredere database, og hvordan dens poster administreres. For en prøve med en enkelt tabel behøver ingen af disse justeringer.

Den vigtige vane at opbygge her er tilbageholdenhed. Nye udviklere åbner ofte en egenskabsdialog og begynder at ændre indstillinger, før de forstår, hvad hver enkelt gør. I 4D, som i det meste relationelle databasedesign, er den sikreste vej at acceptere standardindstillingerne, få en fungerende tabel og kun gense avancerede indstillinger, når et konkret krav tvinger dig til det.

En note om navngivning

For prøvedatabasen skal du navngive den første tabel “Kunder”. Dette er en lille beslutning med store downstream-effekter:

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

• Vær konsekvent med pluralis. Hvis du navngiver denne tabel “Kunder”, skal du navngive den næste “Ordrer” og “Produkter” – ikke “Ordre” og “Produkt”. Konsistens gør relationer og kode langt nemmere at læse.
• Undgå mellemrum og specialtegn, hvor du kan, da tabelnavne ofte optræder i kode og i genererede forespørgsler.
• Navngiv efter enheden, ikke skærmen. “Kunder” beskriver en ting; “CustomerEntryScreen” beskriver en formular. Hold disse begreber adskilt.

Når du har indtastet navnet, skal du klikke på Anvend, og derefter lukke vinduet ved at bruge feltet øverst til venstre eller knappen Udført. Din tabel findes nu i strukturen og er klar til at modtage felter.

Hvordan tabeller passer ind i resten af databasen

En tabel er kun beholderen. Resten af din applikation bygger oven på den i en klar rækkefølge, og det er værd at se det fulde billede, før du fortsætter:

• Datafelter definerer kolonnerne – de faktiske attributter, du gemmer, såsom en kundes navn, adresse eller kontonummer.
• Formularer er brugergrænsefladen: skærmbillederne, hvor folk ser og redigerer poster.
• Værdilister (valglister) begrænser og fremskynder dataindtastning ved at tilbyde foruddefinerede muligheder.
• Eksempeldata giver dig mulighed for at teste formularer og lister med realistisk indhold, før du går live.

Hver af disse afhænger af, at tabellen eksisterer først. Dette er grunden til, at 4D’s design-workflow er bevidst ordnet: struktur før interface, interface før data. Hvis du forsøger at bygge en formular, før de underliggende felter eksisterer, vil du simpelthen ikke have noget at binde dem til.

Det forklarer også, hvorfor modellen med en enkelt datafil betyder så meget. Fordi hver tabel, hvert felt og hver post lever i én koordineret struktur, kan 4D håndhæve relationer og referenceintegritet på tværs af hele din applikation, uden at du skal administrere eksterne filer.

Det er det samme princip, der ligger bag relationelle databasestyringssystemer generelt – konceptet formaliseret i E. F. Codds relationsmodel og nu standard på tværs af produkter som Oracle Database, Microsoft SQL Server og PostgreSQL. 4D anvender den relationelle tænkning inde i en selvstændig applikationsfil, hvilket er det, der gør den tilgængelig for små teams og citizen developers.

Praktisk vejledning til skalering ud over én tabel

Eksemplet bruger en enkelt tabel for klarhedens skyld, men rigtige apps stopper sjældent der. Når du tilføjer tabeller, skal du have disse kriterier i tankerne:

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

Overvejelse	Hvad skal tjekkes	Hvorfor det betyder noget
Tabelantal	Hold dig godt under grænsen på 256 tabeller	Giver luft og holder strukturen overskuelig
Størrelse pr. tabel	Hold øje med loftet på 2 GB / ~16 millioner poster	Store transaktionstabeller kan kræve arkivering eller opdeling
Navngivning	Konsekvent, enhedsbaseret, ingen løse tegn	Påvirker kodelæsbarhed og relationernes klarhed
Relationer	Definer links mellem tabeller bevidst	Forhindrer forældreløse eller duplikerede data
Vækstplan	Beslut tidligt, hvad der skal arkiveres	Beskytter ydeevnen, efterhånden som data akkumuleres

En nyttig tommelfingerregel: modeller én tabel pr. enhed i den virkelige verden (kunder, ordrer, produkter, fakturaer), og forbind dem derefter med relationer i stedet for at proppe alt ind i én bred tabel. Dette afspejler normaliseringsprincipperne, der undervises i i de fleste databasepensum, og holder din 4D-struktur vedligeholdelsesvenlig, efterhånden som appen vokser.

Almindelige fejl at undgå

• At klikke på det forkerte område i strukturvinduet. Kun området for tabelnavnet åbner Tabelegenskaber. Dette er den absolut mest almindelige anstødssten i dette trin.
• Omdøbning af tabeller sent uden at kontrollere afhængigheder. Du kan omdøbe når som helst, men hvis formularer, metoder eller relationer allerede refererer til det gamle navn, skal du opdatere dem.
• At ignorere størrelsesgrænserne, indtil det er for sent. Loftet på 2 GB / 16 millioner poster pr. tabel er generøst, men endeligt. Planlæg arkivering for højvolumen-tabeller.
• At bygge formularer før felter. Workflow-rækkefølgen eksisterer af en grund – definer strukturen først.
• Over-tilpasning af egenskaber på dag ét. Standardindstillingerne er der for at få dig i gang. Ændr dem, når et krav kræver det, ikke før.

Ofte stillede spørgsmål

Hvor mange tabeller kan en 4D-database indeholde?

En 4D-database understøtter op til 256 tabeller. Hver tabel kan indeholde maksimalt 2 GB data, eller cirka 16 millioner poster. For de fleste afdelings- og småteam-applikationer er disse grænser mere end tilstrækkelige, men højvolumen-designs bør planlægge for arkivering.

Hvorfor kan jeg ikke åbne vinduet Tabelegenskaber?

Du klikker næsten helt sikkert på den forkerte del af strukturvinduet. Dialogboksen Tabelegenskaber åbnes kun, når du dobbeltklikker direkte på tabelnavnområdet. At klikke andre steder i vinduet gør intet, så flyt markøren til tabellens navn og prøv igen.

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

Kan jeg omdøbe en tabel efter at have oprettet den?

Ja. Feltet Tabelnavn er synligt på alle tre faner i vinduet Tabelegenskaber, så du kan ændre navnet når som helst. Husk blot, at hvis formularer, metoder eller relationer allerede refererer til det gamle navn, skal du opdatere disse referencer.

Behøver jeg at ændre noget på fanerne for tabelegenskaber?

Ikke til et første projekt. Den oprindelige gennemgang anbefaler at lade standardindstillingerne forblive, og det er god praksis. De tre faner styrer strukturel adfærd, som du ikke får brug for, før et specifikt krav tvinger dig til at besøge dem igen.

Hvordan adskiller en 4D-tabel sig fra en FileMaker Pro-fil?

I FileMaker Pro lå tabeller historisk set i separate filer. I 4D er alle tabeller gemt inde i den enkelte datafil, hvilket centraliserer backup, implementering og adgang for flere brugere. Dette er den vigtigste arkitektoniske forskel, man skal have for øje, når man skifter mellem de to platforme.

Hvad skal jeg kalde min første tabel?

For eksempeldatabasen skal du kalde den “Customers.” Mere generelt skal du vælge entitetsbaserede navne, holde pluralis konsistent på tværs af tabeller og undgå mellemrum eller specialtegn, da tabelnavne ofte optræder i kode og genererede forespørgsler.

Hvad nu

Nu hvor din første tabel er oprettet og navngivet, har du den beholder, din applikation har brug for. Det næste trin er at definere datafelter — de kolonner, der giver tabellen dens substans.

Derfra vil du bygge formularer til brugerfladen, opsætte værdilister for at fremskynde dataindtastning, og til sidst indtaste eksempeldata for at teste alt fra ende til anden. Hvert trin bygger direkte på den tabel, du lige har oprettet, så brug et øjeblik på at bekræfte, at den vises korrekt i strukturvinduet, før du går videre.