Mere end en database

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 1 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Næste: Kig på moderskibet: standarddatamodellerne

Spørgsmålet, dette modul besvarer: Hvad gør Salesforce anderledes end en traditionel database?

Har du været Salesforce-admin et stykke tid, ved du allerede, hvordan man opretter et objekt. Setup, Object Manager, New Custom Object. Giv det et navn, tilføj et par felter, byg et sidelayout, og ti minutter senere kan brugerne arbejde med det.

Men hvad skete der egentlig, da du klikkede på Save?

Kommer du fra databaseverdenen, forestiller du dig sikkert, at Salesforce gik ud og oprettede en ny tabel. Det gjorde den ikke. Og at forstå hvorfor er et af de steder, hvor du begynder at bevæge dig fra at tænke som en admin eller en udvikler til at tænke som en arkitekt.

Salesforce gemmer selvfølgelig data; der ligger databaser nedenunder. Men Salesforce er ikke en database med en pæn skærm ovenpå. Det er en metadatadrevet applikationsplatform, og den forskel former næsten hver eneste beslutning i dette kursus.

Platformen har en form

I kapitel 2 byggede vi modellen uden overhovedet at tænke på Salesforce. Det var med vilje: Vi lyttede efter navneordene, byggede den konceptuelle model, tilføjede attributter, nøgler og relationer, og først derefter spurgte vi, hvordan Salesforce skulle implementere den. Nu skal vi forstå det, vi implementerer den på.

Jeg bruger en enkel sætning til det: platformen har en form. Salesforce giver os objekter, felter, relationer, sikkerhed, automatisering, API’er, transaktioner, rapportering og søgning, og de hænger alle sammen. Når jeg opretter et objekt, opretter jeg ikke bare et sted at lægge rækker. Jeg opretter noget, der indgår i sikkerhedsmodellen, som automatisering kan handle på, som API’erne eksponerer, som rapporter kan bruge, som andre objekter kan relatere til, og som brugere, integrationer og i stigende grad agenter kommer til at afhænge af. Det er meget mere end en tabel.

Metadata er tegningen

Tænk på en bygning. Der er selve bygningen, og der er tegningen, der beskriver den: hvor væggene står, hvor dørene sidder, hvordan rummene hænger sammen. Salesforce fungerer på samme måde. En objektdefinition er metadata. En feltdefinition er metadata. En relation er metadata. Det meste af det, vi konfigurerer i Setup, er metadata, og platformen læser det under kørsel for at give vores org dens struktur og adfærd.

Salesforce beskriver platformens hjerte som både multitenant og metadatadrevet: Når vi definerer et objekt eller et felt, gemmes definitionen som metadata, ikke som en ny fysisk tabel eller kolonne til vores org (Platform Multitenant Architecture (opens in a new tab)).

Når jeg underviser i det her, løfter jeg motorhjelmen. Salesforce opretter ikke en ny database til dig, hver gang du tilføjer et objekt. Den tilføjer en post i sine egne tabeller: en tabel med objekter, en tabel med felter, en tabel med data og pivottabeller til indekser og relationer, alle med en org-identifikator som nøgle, der holder din orgs data adskilt fra alle andres. Så at tilføje et felt er bare at tilføje en række. Derfor kan du oprette et i farten, i frokostpausen, i produktion.

Det forklarer også noget, folk falder over. Når du skriver SELECT Id, Name, Special__c FROM Account, ligner det én tabel. Nedenunder læser du standardobjektet og dets brugerdefinerede felt fra forskellige strukturer, så platformen laver en join, du aldrig har skrevet. Der findes indekser, men de fungerer ikke som et indeks i en traditionel database. Du behøver ikke kende det indre maskineri til eksamen. Men du skal vide, at det, du ser i Object Manager, ikke er et én-til-én-billede af fysiske tabeller, og at abstraktionen både er platformens styrke og grunden til, at den opfører sig, som den gør.

Click to enlarge

Kig på moderskibet

En af de ting, jeg siger til folk i klassen, er: Kig på moderskibet. Før du opfinder en kompliceret måde at gøre noget på i Salesforce, så se på, hvordan Salesforce selv gør det.

Tag konto (Account). Du har ikke oprettet den; det har Salesforce. Men du kan tilføje felter til den, automatisere omkring den, ændre dens layouts, eksponere den gennem API’erne og relatere andre objekter til den. Brugerdefinerede objekter kører på det samme maskineri, og derfor føles standardobjekter og brugerdefinerede objekter så ens, når vi bygger på dem. I Apex deler de endda en basisklasse, sObject.

Det er den vane, dette kapitel bygger på, og i næste modul kigger vi ordentligt efter: på de standarddatamodeller, Salesforce allerede har bygget til dig.

Vi bygger ikke ved siden af Salesforce. Vi udvider den.

Dit API fulgte med objektet

Opret en tabel i en traditionel database, og du har en tabel. Skal en anden applikation arbejde med den, har nogen mere arbejde foran sig. Opret et objekt i Salesforce, og platformen forstår det allerede gennem sine applikations- og integrationslag: Den bruger de samme metadata til at levere sine REST- og SOAP-API’er, så objektets poster kan oprettes, læses, opdateres og slettes gennem dem, så snart objektet findes (Platform Multitenant Architecture (opens in a new tab)).

Jeg har ikke designet et API, fordi jeg oprettede et objekt. Platformen kender objektet, dets felter, deres typer, dets relationer og dets sikkerhed. Det er en af grundene til, at udvikling i Salesforce går så hurtigt. Det er også derfor, det er en større beslutning at oprette et objekt, end det ser ud til: Du kobler en struktur på en hel applikationsplatform. Og det gælder også den anden vej. Folk fra SQL Server eller Oracle spørger mig nogle gange, hvordan de indlæser data direkte i databasen. Det kan man ikke. Alt kommer ind gennem API’erne.

Etageejendommen

Nu kommer ordet, du hører hele tiden: multitenancy. Jeg tænker på det som en etageejendom.

Du har din lejlighed. Dine møbler er dine, og din nøgle skal ikke kunne åbne min dør. Men vi deler bygningen: strømmen, vandet, elevatorerne, opgangen. Din org føles som dit eget miljø med dine data, dine objekter, din automatisering. Nedenunder beskriver Salesforce hver org som en lejer (tenant) og isolerer hver lejers data, metadata og logik, mens infrastrukturen og tjenesterne deles (Platform Multitenant Architecture (opens in a new tab)). Sådan kan den give hver eneste kunde en så tilpasselig platform uden at køre en separat stak til hver af dem.

Men at dele bygningen har konsekvenser. Hvis én lejer køber et kæmpe klimaanlæg og kører hårtørreren og ovnen på samme tid, springer sikringen, og hele etagen går i sort.

Du kan ikke lægge beslag på elevatoren

Bliv i bygningen et øjeblik endnu. Forestil dig, at en beboer meddeler: »Jeg skal bruge elevatoren fra kl. 08.00 til kl. 12.00. Ingen andre må bruge den.« Det fungerer ikke i en delt bygning, og det fungerer heller ikke i Salesforce. Én lejer kan ikke få lov til at bruge delte ressourcer uden grænser og gøre platformen dårligere for alle andre.

Det er derfra, governor limits (platformens grænser) kommer. Har du udviklet i Salesforce, har du sikkert mødt dem som en liste af tal, du skal lære udenad. Sådan vil jeg ikke have, at du tænker på dem. Salesforce anvender grænser på transaktions- og org-niveau, så én lejers arbejdsbyrde ikke monopoliserer den delte regnekraft (Architecture Basics (opens in a new tab)). Det er arkitekturen; hver enkelt grænse er bare implementeringen af den. Senere i kurset kommer vi til at interessere os for bestemte grænser, fordi de ændrer et design. Indtil videre skal du huske bygningen: Du har enorm frihed til at bygge din lejlighed om. Du får ikke lov til at lægge beslag på elevatoren.

Salesforce-id’er er en del af abstraktionen

Hver post i Salesforce har et id, som platformen forstår, post-id’et, og det virker på tværs af alle funktioner: brugerfladen, API’erne, rapporter, automatisering.

I kapitel 2 sagde vi, at en god nøgle er unik, uforanderlig, uden betydning og aldrig personoplysninger (PII). Salesforce-id’et passer til det i Salesforce. Men det er ikke det samme som en forretningsnøgle. Din virksomhed har måske stadig et kundenummer fra ERP-systemet, et medarbejdernummer eller en partners ordrenummer, der betyder noget på tværs af systemer. Bland ikke »Salesforce ved, hvilken post det her er« sammen med »virksomheden ved, hvilken forretningsting det her er«. Det er to forskellige problemer med at identificere ting, og det andet vender tilbage i integration og masterdata.

Objekter er mere end lagerplads

Her er det skift, jeg vil have dig til at foretage før resten af kapitlet. Et objekt er ikke bare et sted at gemme data. Et felt er ikke bare en kolonne, og en relation er ikke bare en fremmednøgle. Jeg bruger databasesammenligningerne, når jeg underviser, fordi de knytter an til det, folk allerede kender. Men hvis vi stopper der, går vi glip af arkitekturen.

Det objekt, vi vælger, afgør, hvilke funktioner der følger med. Felttypen påvirker validering, integration, søgning, rapportering og hvordan andre systemer læser dataene. Relationen afgør livscyklus, ejerskab, deling og sletning. Hvor vi placerer dataene, påvirker lagerplads, ydeevne og skala. Og fordi alt det her kører på en delt platform, kan et valg, der er harmløst med hundrede poster, opføre sig helt anderledes med hundrede millioner. Vi tager de beslutninger én ad gangen.

Ud over eksamen: hvad AI ændrer. I årevis hjalp gode navne og beskrivelser den næste admin eller udvikler med at forstå, hvad vi havde bygget. Nu læser maskiner også den kontekst. Et AI-system, der arbejder med et felt ved navn Flag2__c, har samme problem som en ny udvikler: Hvad betyder det her? Metadata er ikke længere pynt; det er en del af, hvordan maskiner forstår applikationen.

Hvad en arkitekt beslutter her

• Designer jeg til den platform, jeg faktisk står på, eller behandler jeg Salesforce som en generisk database?
• Hvilke dele af mit design er forretningsbegreber, og hvilke er implementeringsvalg i Salesforce?
• Hvilken platformsadfærd følger med den struktur, jeg er ved at oprette?
• Hvilke grænser er udtryk for den delte arkitektur, og hvilke af dem kommer til at forme dette design?
• Hvis denne struktur bliver svær at ændre senere, behandler jeg den så som en arkitektonisk beslutning?

I kapitel 2 sagde vi: Design ikke ud fra Setup. Nu kender du en grund mere. Et klik på New Custom Object giver dig ikke bare en tabel; det kobler endnu en del af din arkitektur til en metadatadrevet multitenant-platform. Men før du beslutter, hvilket objekt du skal oprette, er der et mere grundlæggende spørgsmål: Skal disse data overhovedet bo her? Det kommer næste gang.

Læs mere

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab), på engelsk, kontrolleret 2026-10-02, genkontrolleret 2026-10-12: Objekt- og feltdefinitioner gemmes som metadata, ikke som nye tabeller; delte tabeller (MT_Objects, MT_Fields, MT_Data, MT_Indexes) med OrgID som nøgle; de samme metadata leverer REST- og SOAP-API’erne.
• Salesforce Architects, Architecture Basics (opens in a new tab), på engelsk, kontrolleret 2026-10-02, genkontrolleret 2026-10-12: governor limits og eksekveringsgrænser, så kode og transaktioner ikke monopoliserer de delte regneressourcer (»don’t monopolize shared compute resources«).