Mer än en databas

🌐 Finns även på 28 språk

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 1 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Nästa: Titta på moderskeppet: standarddatamodellerna

Frågan den här modulen besvarar: Vad gör Salesforce annorlunda än en traditionell databas?

Har du varit Salesforce-admin ett tag vet du redan hur man skapar ett objekt. Setup, Object Manager, New Custom Object. Ge det ett namn, lägg till några fält, bygg en sidlayout, och tio minuter senare kan användarna jobba med det.

Men vad hände egentligen när du klickade på Save?

Kommer du från databasvärlden föreställer du dig förmodligen att Salesforce gick iväg och skapade en ny tabell. Det gjorde det inte. Och att förstå varför är ett av de ställen där du börjar gå från att tänka som en admin eller utvecklare till att tänka som en arkitekt.

Salesforce lagrar förstås data; det finns databaser där under. Men Salesforce är inte en databas med en snygg skärm ovanpå. Det är en metadatadriven applikationsplattform, och den skillnaden formar nästan varje beslut i den här kursen.

Plattformen har en form

I kapitel 2 byggde vi modellen utan att bry oss om Salesforce alls. Det var med flit: vi lyssnade efter substantiven, byggde den konceptuella modellen, lade till attribut, nycklar och relationer, och först därefter frågade vi hur Salesforce skulle implementera den. Nu måste vi förstå det vi implementerar den på.

Jag använder en enkel fras för det här: plattformen har en form. Salesforce ger oss objekt, fält, relationer, säkerhet, automatisering, API:er, transaktioner, rapportering och sökning, och allt hänger ihop. När jag skapar ett objekt skapar jag inte bara ett ställe att lägga rader på. Jag skapar något som deltar i säkerhetsmodellen, som automatisering kan agera på, som API:erna exponerar, som rapporter kan använda, som andra objekt kan relatera till, och som användare, integrationer och, allt oftare, agenter kommer att vara beroende av. Det är mycket mer än en tabell.

Metadata är ritningen

Tänk på en byggnad. Det finns själva byggnaden, och det finns ritningen som beskriver den: var väggarna står, var dörrarna sitter, hur rummen hänger ihop. Salesforce fungerar på samma sätt. En objektdefinition är metadata. En fältdefinition är metadata. En relation är metadata. Det mesta vi konfigurerar i Setup är metadata, och plattformen läser den vid körning för att ge vår org dess struktur och beteende.

Salesforce beskriver plattformens hjärta som både multitenant och metadatadrivet: när vi definierar ett objekt eller ett fält lagras definitionen som metadata, inte som en ny fysisk tabell eller kolumn för vår org (Platform Multitenant Architecture (opens in a new tab)).

När jag undervisar om det här öppnar jag motorhuven. Salesforce skapar inte en ny databas åt dig varje gång du lägger till ett objekt. Det lägger till en post i sina egna tabeller: en tabell med objekt, en tabell med fält, en tabell med data och pivottabeller för index och relationer, alla nycklade på en org-identifierare som håller din orgs data åtskilda från alla andras. Att lägga till ett fält är alltså bara att lägga till en rad. Därför kan du skapa ett i farten, på lunchen, i produktion.

Det förklarar också något som folk snubblar på. När du skriver SELECT Id, Name, Special__c FROM Account ser det ut som en tabell. Under ytan läser du standardobjektet och dess anpassade fält från olika strukturer, så plattformen gör en join som du aldrig skrev. Index finns, men de fungerar inte som index i en traditionell databas. Du behöver inte kunna det inre maskineriet till provet. Men du behöver veta att det du ser i Object Manager inte är en exakt bild av fysiska tabeller, och att abstraktionen både är plattformens styrka och anledningen till att den beter sig som den gör.

Click to enlarge

Titta på moderskeppet

En sak jag säger till folk i klassrummet är att titta på moderskeppet. Innan du hittar på något komplicerat sätt att göra något i Salesforce, titta på hur Salesforce själv gör det.

Ta konto (Account). Du skapade det inte; det gjorde Salesforce. Men du kan lägga till fält på det, automatisera runt det, ändra dess layouter, exponera det via API:erna och relatera andra objekt till det. Anpassade objekt körs på samma maskineri, och därför känns standardobjekt och anpassade objekt så lika när vi bygger på dem. I Apex delar de till och med basklass, sObject.

Det är den vanan som det här kapitlet bygger vidare på, och i nästa modul tittar vi ordentligt: på standarddatamodellerna som Salesforce redan har byggt åt dig.

Vi bygger inte bredvid Salesforce. Vi bygger ut det.

Ditt API följde med objektet

Skapa en tabell i en traditionell databas så har du en tabell. Behöver en annan applikation jobba med den har någon mer arbete att göra. Skapa ett objekt i Salesforce, så förstår plattformen det redan genom sina applikations- och integrationslager: den använder samma metadata för att tillhandahålla sina REST- och SOAP-API:er, så objektets poster kan skapas, läsas, uppdateras och raderas genom dem så fort objektet finns (Platform Multitenant Architecture (opens in a new tab)).

Jag designade inget API bara för att jag skapade ett objekt. Plattformen känner till objektet, dess fält, deras typer, dess relationer och dess säkerhet. Det är en anledning till att utveckling i Salesforce går så snabbt. Det är också därför det är ett större beslut än det ser ut att skapa ett objekt: du kopplar in en struktur i en hel applikationsplattform. Och det gäller åt andra hållet också. Folk som kommer från SQL Server eller Oracle frågar mig ibland hur man laddar data direkt in i databasen. Det går inte. Allt kommer in via API:erna.

Hyreshuset

Nu ordet du hör hela tiden: multitenancy. Jag tänker på det som ett hyreshus.

Du har din lägenhet. Dina möbler är dina, och din nyckel ska inte öppna min dörr. Men vi delar huset: elen, vattnet, hissarna, entrén. Din org känns som din egen miljö, med dina data, dina objekt, din automatisering. Under ytan beskriver Salesforce varje org som en hyresgäst (tenant), och isolerar varje hyresgästs data, metadata och logik medan infrastrukturen och tjänsterna delas (Platform Multitenant Architecture (opens in a new tab)). Det är så Salesforce kan ge varje kund en så anpassningsbar plattform utan att köra en separat stack för var och en.

Men att dela hus får konsekvenser. Om en hyresgäst köper en jättelik luftkonditionering och kör hårtorken och ugnen samtidigt går proppen, och hela våningen blir mörk.

Du kan inte ta över hissen

Stanna kvar i huset en stund till. Tänk dig att en boende meddelar: ”Jag behöver hissen från 08.00 till 12.00. Ingen annan får använda den.” Det fungerar inte i ett delat hus, och det fungerar inte i Salesforce heller. En hyresgäst kan inte få förbruka delade resurser utan gräns och försämra plattformen för alla andra.

Det är därifrån governor limits (plattformens gränser) kommer. Har du utvecklat i Salesforce har du förmodligen mött dem som en lista med siffror att plugga in. Jag vill inte att du tänker på dem så. Salesforce tillämpar gränser på transaktions- och orgnivå så att en hyresgästs arbetslast inte monopoliserar delad beräkningskraft (Architecture Basics (opens in a new tab)). Det är arkitekturen; varje enskild gräns är bara implementeringen av den. Senare i kursen bryr vi oss om vissa gränser eftersom de ändrar en design. Just nu: kom ihåg huset. Du har enorm frihet att renovera din lägenhet. Du får inte ta över hissen.

Salesforce-ID:n är en del av abstraktionen

Varje post i Salesforce har en identifierare som plattformen förstår, post-ID:t, och den fungerar i alla funktioner: gränssnittet, API:erna, rapporter, automatisering.

I kapitel 2 sa vi att en bra nyckel är unik, oföränderlig, betydelselös och aldrig personuppgifter (PII). Salesforce-ID:t uppfyller det för Salesforce. Men det är inte samma sak som en affärsnyckel. Ditt företag kan fortfarande ha ett kundnummer i ERP-systemet, ett anställningsnummer eller en partners ordernummer som betyder något över flera system. Blanda inte ihop ”Salesforce vet vilken post det här är” med ”företaget vet vilken affärssak det här är”. Det är två olika identifieringsproblem, och det andra kommer tillbaka i integration och masterdata.

Objekt är mer än lagring

Här är skiftet jag vill att du gör innan resten av kapitlet. Ett objekt är inte bara ett ställe att lagra data på. Ett fält är inte bara en kolumn, och en relation är inte bara en främmande nyckel. Jag använder databasjämförelserna när jag undervisar, eftersom de knyter an till det folk redan kan. Men stannar vi där missar vi arkitekturen.

Objektet vi väljer avgör vilka funktioner som följer med. Fälttypen påverkar validering, integration, sökning, rapportering och hur andra system läser data. Relationen avgör livscykel, ägarskap, delning och radering. Var vi lägger data påverkar lagring, prestanda och skala. Och eftersom allt det här körs på en delad plattform kan ett val som är ofarligt med hundra poster bete sig helt annorlunda med hundra miljoner. Vi tar de besluten ett i taget.

Bortom provet: vad AI förändrar. I åratal hjälpte bra namn och beskrivningar nästa admin eller utvecklare att förstå vad vi byggt. Nu läser maskiner också det sammanhanget. Ett AI-system som jobbar med ett fält som heter Flag2__c har samma problem som en ny utvecklare: vad betyder det här? Metadata är inte dekoration längre; det är en del av hur maskiner förstår applikationen.

Vad en arkitekt bestämmer här

• Designar jag för den plattform jag faktiskt är på, eller behandlar jag Salesforce som en generisk databas?
• Vilka delar av min design är affärsbegrepp, och vilka är implementeringsval i Salesforce?
• Vilket plattformsbeteende följer med strukturen jag är på väg att skapa?
• Vilka gränser är uttryck för den delade arkitekturen, och vilka av dem kommer att forma den här designen?
• Om den här strukturen blir svår att ändra senare, behandlar jag den då som ett arkitekturbeslut?

I kapitel 2 sa vi: designa inte utifrån Setup. Nu vet du ytterligare en anledning. Att klicka på New Custom Object ger dig inte bara en tabell; det kopplar ytterligare en del av din arkitektur till en metadatadriven multitenant-plattform. Men innan du bestämmer vilket objekt du ska skapa finns det en mer grundläggande fråga: ska de här data bo här över huvud taget? Det kommer härnäst.

Utforska vidare

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (på engelska, kontrollerad 2026-10-02, kontrollerad igen 2026-10-12): objekt- och fältdefinitioner lagras som metadata, inte som nya tabeller; delade tabeller (MT_Objects, MT_Fields, MT_Data, MT_Indexes) nycklade på OrgID; samma metadata tillhandahåller REST- och SOAP-API:erna.
• Salesforce Architects, Architecture Basics (opens in a new tab) (på engelska, kontrollerad 2026-10-02, kontrollerad igen 2026-10-12): governor limits och exekveringsgränser så att kod och transaktioner inte ”monopoliserar delade beräkningsresurser”.