Grunderna i 4th Dimension Learning

4D-plattformen – ursprungligen 4th Dimension, och fortfarande allmänt känd under sitt historiska namn – lagrar en hel applikations data i en enda strukturerad datafil. Att förstå hur tabeller passar in i den arkitekturen är grunden för allt annat du kommer att bygga: fält, formulär, värdelistor och så småningom de frågor och metoder som driver en riktig affärsapp. Det här avsnittet går igenom hur du skapar din första tabell, öppnar dess egenskaper och namnger den på rätt sätt, samtidigt som resonemanget bakom varje steg förklaras så att du kan tillämpa det med tillförsikt på större designer.

Viktiga punkter

• I 4D finns alla tabeller i en datafil snarare än i separata filer som i FileMaker Pro (FMP). Denna enfilsmodell är central för hur 4D hanterar säkerhetskopiering, distribution och fleranvändaråtkomst.
• En 4D-databas stöder upp till 256 tabeller, var och en med maximalt 2 GB data eller ungefär 16 miljoner poster.
• Du skapar tabeller från menyn Struktur när du är i designläge.
• För att öppna en tabells egenskaper måste du dubbelklicka specifikt på området för tabellnamn – om du klickar någon annanstans i strukturfönstret öppnas inte dialogrutan för egenskaper.
• Fönstret Tabellegenskaper har tre flikar; standardinställningarna är säkra för ett första projekt, och tabellnamnet kan ändras när som helst.
• Namnkonventioner spelar roll: välj tydliga namn som är konsekventa i singular eller plural, till exempel “Kunder”, innan du bygger formulär och relationer ovanpå dem.

Varför tabeller är viktiga i 4D-datamodellen

Om du kommer från en FileMaker Pro-bakgrund är det mentala skiftet viktigt. I FMP levde varje tabell historiskt i sin egen fil, och relationer hanterades över filer. I 4D är arkitekturen annorlunda: alla tabeller lagras i den enda datafilen. Strukturen (din design – tabeller, fält, formulär, metoder) hålls separat från data (de faktiska poster som användarna anger), men varje tabell som du definierar finns i den enda datafilen.

Denna design har praktiska konsekvenser som formar hur du arbetar:

• Säkerhetskopiering är enklare. Eftersom data är centraliserad säkerhetskopierar du en datafil istället för att hålla reda på många.
• Distributionen är renare. Du levererar en struktur och en datafil, inte en mapp full av ömsesidigt beroende dokument.
• Fleranvändaråtkomst är inbyggt. 4D Server hanterar samtidig åtkomst till den enda datafilen, så du behöver inte konstruera egna system för fillåsning.

Avvägningen är att datafilen blir den enda tillväxtpunkten. Det är precis därför 4D inför gränser per tabell — upp till 256 tabeller, var och en begränsad till 2 GB eller cirka 16 miljoner poster. För de flesta företagsappar för små team och avdelningar är dessa tak generösa. Men om du designar något som kommer att ackumulera miljontals transaktionsrader bör du tidigt tänka på hur du delar upp data mellan tabeller och om du behöver arkivera äldre poster.

Skapa en tabell steg för steg

För den här genomgången kommer vi bara att skapa en tabell, vilket gör att exempeldatabasen är lätt att följa. Samma procedur kan skalas upp till många tabeller.

1. Gå in i designläge. Att skapa tabeller är en strukturell förändring, så du måste vara i designläge. Du kan inte lägga till tabeller när applikationen körs i användarläge.
2. Öppna menyn Struktur. Välj menyn Struktur i menyraden.
3. Välj “Ny tabell”. Detta menyalternativ lägger till en ny, tom tabell i din struktur.
4. Leta reda på den nya tabellen i strukturfönstret. Fönstret Struktur för exempeldatabas (Figur 6 i den ursprungliga genomgången) visar dina tabeller. En nyskapad tabell visas som en namnlös post.
5. Dubbelklicka på området för tabellnamn. Detta öppnar fönstret Tabellegenskaper (Figur 7).

Det sista steget har en varning som är värd att upprepa, eftersom den ofta förvirrar nybörjare: du måste klicka på området för tabellnamn och inte någon annanstans. Strukturfönstret innehåller flera regioner, och endast namnområdet svarar genom att öppna dialogrutan Tabellegenskaper. Om inget händer när du dubbelklickar klickar du nästan säkert på fel ställe — flytta markören direkt till tabellens namn och försök igen.

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

Förstå fönstret Tabellegenskaper

När fönstret Tabellegenskaper öppnas ser du tre flikar. Den ursprungliga vägledningen är att lämna dem på sina standardvärden för tillfället, och det är ett bra råd för ett första projekt – men det hjälper att veta vad du skjuter upp.

• Fältet Tabellnamn förblir synligt på varje flik. Detta är ett medvetet designval: oavsett vilken flik du tittar på kan du byta namn på tabellen. Du kan ändra namnet när som helst, så ett namn är aldrig permanent.
• De andra flikarna styr strukturellt beteende — saker som hur tabellen deltar i den bredare databasen och hur dess poster hanteras. För ett exempel med en enda tabell behöver inget av detta justeras.

Den viktiga vanan att bygga här är återhållsamhet. Nya utvecklare öppnar ofta en egenskapsdialog och börjar ändra alternativ innan de förstår vad varje alternativ gör. I 4D, som i de flesta relationsdatabasdesigner, är den säkraste vägen att acceptera standardinställningarna, få en fungerande tabell och återvända till avancerade inställningar endast när ett konkret krav tvingar dig till det.

En notering om namngivning

För exempeldatabasen, namnge den första tabellen “Kunder”. Detta är ett litet beslut med stora effekter längre fram i processen:

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

• Var konsekvent med pluralis. Om du namnger den här tabellen “Kunder”, namnge nästa “Beställningar” och “Produkter” — inte “Beställning” och “Produkt”. Konsekvens gör relationer och kod mycket lättare att läsa.
• Undvik mellanslag och specialtecken där du kan, eftersom tabellnamn ofta förekommer i kod och i genererade frågor.
• Namnge efter enheten, inte skärmen. “Kunder” beskriver en sak; “CustomerEntryScreen” beskriver ett formulär. Håll dessa begrepp åtskilda.

När du har skrivit namnet, klicka på Använd, och stäng sedan fönstret med rutan uppe till vänster eller knappen Klar. Din tabell finns nu i strukturen och är redo att ta emot fält.

Hur tabeller passar med resten av databasen

En tabell är bara behållaren. Resten av din applikation bygger ovanpå den i en tydlig sekvens, och det är värt att se hela bilden innan du fortsätter:

• Datafält definierar kolumnerna — de faktiska attributen du lagrar, såsom en kunds namn, adress eller kontonummer.
• Formulär är användargränssnittet: skärmarna där användare visar och redigerar poster.
• Värdelistor (val-listor) begränsar och påskyndar datainmatning genom att erbjuda fördefinierade alternativ.
• Exempeldata låter dig testa formulär och listor med realistiskt innehåll innan du går live.

Var och en av dessa beror på att tabellen skapas först. Det är därför 4D:s designarbetsflöde är avsiktligt ordnat: struktur före gränssnitt, gränssnitt före data. Om du försöker bygga ett formulär innan de underliggande fälten finns, kommer du helt enkelt inte ha något att binda till.

Det förklarar också varför modellen med en enda datafil är så viktig. Eftersom varje tabell, fält och post lever i en koordinerad struktur, kan 4D upprätthålla relationer och referensintegritet över hela din applikation utan att du behöver hantera externa filer.

Det är samma princip som bakom relationsdatabashanteringssystem generellt — konceptet formaliserades i E. F. Codds relationsmodell och är nu standard i produkter som Oracle Database, Microsoft SQL Server och PostgreSQL. 4D tillämpar detta relationstänkande inuti en fristående applikationsfil, vilket gör det lättillgängligt för små team och medborgarutvecklare.

Praktisk vägledning för skalning bortom en tabell

Exemplet använder en enda tabell för tydlighetens skull, men riktiga appar stannar sällan där. När du lägger till tabeller, tänk på dessa kriterier:

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

Övervägande	Vad som ska kontrolleras	Varför det är viktigt
Tabellantal	Håll dig väl under gränsen på 256 tabeller	Ger utrymme och håller strukturen navigerbar
Storlek per tabell	Beakta taket på 2 GB / ~16 miljoner poster	Stora transaktionstabeller kan behöva arkiveras eller delas
Namngivning	Konsekvent, enhetsbaserad, inga lösa tecken	Påverkar kodläsbarhet och relationernas tydlighet
Relationer	Definiera länkar mellan tabeller medvetet	Förhindrar föräldralös eller duplicerad data
Tillväxtplan	Bestäm tidigt vad som ska arkiveras	Skyddar prestandan när data ackumuleras

En användbar tumregel: modellera en tabell per verklig enhet (kunder, beställningar, produkter, fakturor), och koppla dem sedan samman med relationer istället för att klämma in allt i en bred tabell. Detta speglar normaliseringsprinciperna som lärs ut i de flesta databaskurser och håller din 4D-struktur underhållbar när appen växer.

Vanliga misstag att undvika

• Klicka på fel område i strukturfönstret. Endast området för tabellnamnet öppnar Tabellegenskaper. Detta är det absolut vanligaste hindret i detta steg.
• Byta namn på tabeller sent utan att kontrollera beroenden. Du kan byta namn när som helst, men om formulär, metoder eller relationer redan refererar till det gamla namnet, måste du uppdatera dem.
• Ignorera storleksgränserna tills det är för sent. Taket på 2 GB / 16 miljoner poster per tabell är generöst men ändligt. Planera arkivering för högvolymstabeller.
• Bygga formulär före fält. Arbetsflödets ordning finns av en anledning — definiera strukturen först.
• Överanpassa egenskaper från dag ett. Standardinställningarna finns där för att hjälpa dig komma igång. Ändra dem när ett krav kräver det, inte före.

Vanliga frågor

Hur många tabeller kan en 4D-databas innehålla?

En 4D-databas stöder upp till 256 tabeller. Varje tabell kan innehålla maximalt 2 GB data, eller ungefär 16 miljoner poster. För de flesta avdelnings- och småteamapplikationer är dessa gränser mer än tillräckliga, men design för stora volymer bör planera för arkivering.

Varför kan jag inte öppna fönstret Tabellegenskaper?

Du klickar nästan säkert på fel del av strukturfönstret. Dialogrutan Tabellegenskaper öppnas endast när du dubbelklickar direkt på området för tabellnamnet. Att klicka någon annanstans i fönstret gör ingenting, så flytta markören till tabellens namn och försök igen.

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

Kan jag byta namn på en tabell efter att ha skapat den?

Ja. Fältet Tabellnamn är synligt på alla tre flikar i fönstret Tabellegenskaper, så du kan ändra namnet när som helst. Kom bara ihåg att om formulär, metoder eller relationer redan refererar till det gamla namnet, måste du uppdatera dessa referenser.

Behöver jag ändra något på flikarna för Tabellegenskaper?

Inte för ett första projekt. Den ursprungliga genomgången rekommenderar att man behåller standardinställningarna, vilket är god praxis. De tre flikarna styr strukturellt beteende som du inte kommer att behöva förrän ett specifikt krav tvingar dig att återvända till dem.

Hur skiljer sig en 4D-tabell från en FileMaker Pro-fil?

I FileMaker Pro har tabeller historiskt sett funnits i separata filer. I 4D lagras alla tabeller i en enda datafil, vilket centraliserar säkerhetskopiering, distribution och fleranvändaråtkomst. Detta är den viktigaste arkitektoniska skillnaden att ha i åtanke när man flyttar mellan de två plattformarna.

Vad ska jag döpa min första tabell till?

För exempeldatabasen, döp den till “Customers.” Mer generellt, välj enhetsbaserade namn, håll pluralis konsekvent mellan tabellerna och undvik mellanslag eller specialtecken eftersom tabellnamn ofta förekommer i kod och genererade frågor.

Vart ska man gå härnäst

Med din första tabell skapad och namngiven har du den behållare som din applikation behöver. Nästa steg är att definiera datafält — kolumnerna som ger tabellen dess substans.

Därifrån kommer du att bygga formulär för gränssnittet, koppla värdelistor för att påskynda datainmatningen och slutligen mata in exempeldata för att testa allt från början till slut. Varje steg bygger direkt på tabellen du just skapade, så ta en stund för att bekräfta att den visas korrekt i strukturfönstret innan du går vidare.