Mer enn en database

🌐 Finnes også 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 · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 1 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Neste: Se til moderskipet: standarddatamodellene

Spørsmålet denne modulen besvarer: Hva skiller Salesforce fra en tradisjonell database?

Har du vært Salesforce-admin en stund, vet du allerede hvordan du lager et objekt. Setup, Object Manager, New Custom Object. Gi det et navn, legg til noen felt, bygg et sideoppsett, og ti minutter senere kan brukerne jobbe med det.

Men hva skjedde egentlig da du klikket Save?

Kommer du fra databaseverdenen, ser du sikkert for deg at Salesforce gikk og laget en ny tabell. Det gjorde den ikke. Og å forstå hvorfor er et av stedene der du begynner å gå fra å tenke som en admin eller en utvikler til å tenke som en arkitekt.

Salesforce lagrer selvfølgelig data; det ligger databaser under. Men Salesforce er ikke en database med en pen skjerm oppå. Det er en metadatadrevet applikasjonsplattform, og det skillet former nesten hver eneste beslutning i dette kurset.

Plattformen har en form

I kapittel 2 bygde vi modellen uten å tenke på Salesforce i det hele tatt. Det var med vilje: vi lyttet etter substantivene, bygde den konseptuelle modellen, la til attributter, nøkler og relasjoner, og først da spurte vi hvordan Salesforce skulle implementere den. Nå må vi forstå det vi implementerer den på.

Jeg bruker et enkelt uttrykk for dette: plattformen har en form. Salesforce gir oss objekter, felt, relasjoner, sikkerhet, automatisering, API-er, transaksjoner, rapportering og søk, og alt henger sammen. Når jeg lager et objekt, lager jeg ikke bare et sted å legge rader. Jeg lager noe som er med i sikkerhetsmodellen, som automatisering kan handle på, som API-ene eksponerer, som rapporter kan bruke, som andre objekter kan relateres til, og som brukere, integrasjoner og i stadig større grad agenter kommer til å være avhengige av. Det er mye mer enn en tabell.

Metadata er tegningen

Tenk på en bygning. Det er selve bygningen, og det er tegningen som beskriver den: hvor veggene står, hvor dørene skal sitte, hvordan rommene henger sammen. Salesforce fungerer på samme måte. En objektdefinisjon er metadata. En feltdefinisjon er metadata. En relasjon er metadata. Det meste av det vi konfigurerer i Setup, er metadata, og plattformen leser det mens den kjører for å gi orgen vår struktur og oppførsel.

Salesforce beskriver kjernen i plattformen som både multitenant (flere leietakere) og metadatadrevet: når vi definerer et objekt eller et felt, lagres definisjonen som metadata, ikke som en ny fysisk tabell eller kolonne for orgen vår (Platform Multitenant Architecture (opens in a new tab)).

Når jeg underviser i dette, åpner jeg panseret. Salesforce lager ikke en ny database til deg hver gang du legger til et objekt. Den legger til en post i sine egne tabeller: en tabell med objekter, en tabell med felt, en tabell med data og pivottabeller for indekser og relasjoner, alle med en org-identifikator som nøkkel, som holder orgens data adskilt fra alle andres. Å legge til et felt er altså bare å legge til en oppføring. Det er derfor du kan lage et i farta, i lunsjen, i produksjon.

Det forklarer også noe folk snubler i. Når du skriver SELECT Id, Name, Special__c FROM Account, ser det ut som én tabell. Under panseret leser du standardobjektet og det egendefinerte feltet fra forskjellige strukturer, så plattformen gjør en join du aldri skrev. Indekser finnes, men de fungerer ikke slik en indeks i en tradisjonell database gjør. Du trenger ikke kunne innmaten til eksamen. Men du må vite at det du ser i Object Manager, ikke er et én-til-én-bilde av fysiske tabeller, og at abstraksjonen både er plattformens styrke og grunnen til at den oppfører seg som den gjør.

Click to enlarge

Se til moderskipet

Noe av det jeg sier til folk på kurs, er å se til moderskipet. Før du finner opp en komplisert måte å gjøre noe på i Salesforce, se på hvordan Salesforce selv gjør det.

Ta konto (Account). Du laget den ikke; det gjorde Salesforce. Men du kan legge til felt på den, automatisere rundt den, endre oppsettene, eksponere den gjennom API-ene og relatere andre objekter til den. Egendefinerte objekter kjører på det samme maskineriet, og derfor føles standardobjekter og egendefinerte objekter så like når vi bygger på dem. I Apex deler de til og med en baseklasse, sObject.

Det er vanen dette kapitlet bygger på, og i neste modul ser vi ordentlig etter: på standarddatamodellene Salesforce allerede har bygd for deg.

Vi bygger ikke ved siden av Salesforce. Vi utvider den.

API-et fulgte med objektet

Lag en tabell i en tradisjonell database, og du har en tabell. Trenger en annen applikasjon å jobbe med den, har noen mer arbeid foran seg. Lag et objekt i Salesforce, og plattformen forstår det allerede gjennom applikasjons- og integrasjonslagene sine: den bruker den samme metadataen til å levere REST- og SOAP-API-ene, så objektets poster kan opprettes, leses, oppdateres og slettes gjennom dem straks objektet finnes (Platform Multitenant Architecture (opens in a new tab)).

Jeg designet ikke et API fordi jeg laget et objekt. Plattformen kjenner objektet, feltene, typene deres, relasjonene og sikkerheten. Det er én grunn til at utvikling i Salesforce går så fort. Det er også grunnen til at det å lage et objekt er en større beslutning enn det ser ut som: du kobler en struktur inn i en hel applikasjonsplattform. Og det gjelder andre veien også. Folk fra SQL Server eller Oracle spør meg av og til hvordan de laster data rett inn i databasen. Det kan du ikke. Alt kommer gjennom API-ene.

Bygården

Så ordet du hører hele tiden: multitenancy (flere leietakere på samme plattform). Jeg tenker på det som en bygård.

Du har leiligheten din. Møblene er dine, og nøkkelen din skal ikke åpne døren min. Men vi deler bygningen: strømmen, vannet, heisene, inngangspartiet. Orgen din føles som ditt eget miljø, med dine data, dine objekter, din automatisering. Under panseret beskriver Salesforce hver org som en leietaker (tenant), og holder hver leietakers data, metadata og logikk adskilt mens infrastrukturen og tjenestene deles (Platform Multitenant Architecture (opens in a new tab)). Slik kan den gi hver kunde en så tilpassbar plattform uten å kjøre en egen stack for hver av dem.

Men å dele bygning har konsekvenser. Kjøper én leietaker et digert klimaanlegg og kjører hårføneren og stekeovnen samtidig, går sikringen, og hele etasjen blir mørk.

Du kan ikke legge beslag på heisen

Bli i bygningen et øyeblikk til. Se for deg at en beboer kunngjør: «Jeg trenger heisen fra åtte til tolv. Ingen andre får bruke den.» Det fungerer ikke i en delt bygning, og det fungerer ikke i Salesforce heller. Én leietaker kan ikke få bruke delte ressurser uten grenser og gjøre plattformen dårligere for alle andre.

Det er der governor limits (plattformens grenser) kommer fra. Har du utviklet i Salesforce, har du sikkert møtt dem som en liste med tall du skal pugge. Jeg vil ikke at du skal tenke på dem slik. Salesforce legger grenser på transaksjons- og orgnivå slik at én leietakers arbeidsmengde ikke legger beslag på delt regnekraft (Architecture Basics (opens in a new tab)). Det er arkitekturen; hver enkelt grense er bare implementasjonen av den. Senere i kurset bryr vi oss om bestemte grenser fordi de endrer et design. Inntil videre: husk bygningen. Du har enorm frihet til å pusse opp leiligheten din. Du får ikke legge beslag på heisen.

Salesforce-ID-er er en del av abstraksjonen

Hver post i Salesforce har en ID plattformen forstår, post-ID-en, og den fungerer på tvers av alle funksjonene: brukergrensesnittet, API-ene, rapporter, automatisering.

I kapittel 2 sa vi at en god nøkkel er unik, uforanderlig, meningsløs og aldri personopplysninger (PII). Salesforce-ID-en oppfyller det for Salesforce. Men den er ikke det samme som en forretningsnøkkel. Bedriften din kan fortsatt ha et kundenummer i ERP, et ansattnummer eller en partners ordrenummer som betyr noe på tvers av systemer. Ikke bland sammen «Salesforce vet hvilken post dette er» og «virksomheten vet hvilken forretningsting dette er». Det er to forskjellige identifiseringsproblemer, og det andre kommer tilbake i integrasjon og masterdata.

Objekter er mer enn lagring

Her er skiftet jeg vil at du skal gjøre før resten av kapitlet. Et objekt er ikke bare et sted å lagre data. Et felt er ikke bare en kolonne, og en relasjon er ikke bare en fremmednøkkel. Jeg bruker databasesammenligningene når jeg underviser, fordi de kobler til noe folk allerede kan. Men stopper vi der, går vi glipp av arkitekturen.

Objektet vi velger, bestemmer hvilke funksjoner som følger med. Felttypen påvirker validering, integrasjon, søk, rapportering og hvordan andre systemer leser dataene. Relasjonen bestemmer livssyklus, eierskap, deling og sletting. Hvor vi legger dataene, påvirker lagring, ytelse og skala. Og fordi alt dette kjører på en delt plattform, kan et valg som er harmløst med hundre poster, oppføre seg helt annerledes med hundre millioner. Vi tar de beslutningene én om gangen.

Utover eksamen: hva KI endrer. I årevis hjalp gode navn og beskrivelser neste admin eller utvikler med å forstå det vi bygde. Nå leser maskiner den konteksten også. Et KI-system som jobber med et felt kalt Flag2__c, har samme problem som en ny utvikler: hva betyr denne tingen? Metadata er ikke pynt lenger; det er en del av hvordan maskiner forstår applikasjonen.

Hva en arkitekt bestemmer her

• Designer jeg for plattformen jeg faktisk er på, eller behandler jeg Salesforce som en generisk database?
• Hvilke deler av designet mitt er forretningsbegreper, og hvilke er implementasjonsvalg i Salesforce?
• Hvilken plattformoppførsel følger med strukturen jeg er i ferd med å lage?
• Hvilke grenser er uttrykk for den delte arkitekturen, og hvilke av dem kommer til å forme dette designet?
• Hvis denne strukturen blir vanskelig å endre senere, behandler jeg den da som en arkitekturbeslutning?

I kapittel 2 sa vi: ikke design fra Setup. Nå vet du en grunn til. Å klikke New Custom Object gir deg ikke bare en tabell; det kobler enda en del av arkitekturen din til en metadatadrevet plattform med mange leietakere. Men før du bestemmer hvilket objekt du skal lage, kommer et mer grunnleggende spørsmål: skal disse dataene i det hele tatt bo her? Det kommer neste.

Les mer

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab), på engelsk, kontrollert 2026-10-02, kontrollert på nytt 2026-10-12: objekt- og feltdefinisjoner lagres som metadata, ikke som nye tabeller; delte tabeller (MT_Objects, MT_Fields, MT_Data, MT_Indexes) med OrgID som nøkkel; den samme metadataen leverer REST- og SOAP-API-ene.
• Salesforce Architects, Architecture Basics (opens in a new tab), på engelsk, kontrollert 2026-10-02, kontrollert på nytt 2026-10-12: governor limits og kjøringsgrenser slik at kode og transaksjoner ikke legger beslag på delte regneressurser («don’t monopolize shared compute resources»).