Hvor bor disse dataene?
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)
Modul 4 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Bygg ditt eget: egendefinerte objekter · Neste: Velg riktig objekt
Spørsmålet denne modulen besvarer: før du lager et objekt, hvor bør disse dataene egentlig bo: på core i Salesforce, referert der de allerede ligger, eller arkivert?
La meg stille deg et spørsmål. Et nytt krav lander på pulten din. Hva er det første du gjør?
Er du som de fleste av oss, åpner du Setup og lager et egendefinert objekt. Jeg skjønner det. På ti minutter har du en fane, et sideoppsett og en listevisning. Og her er det jeg sier til hver eneste klasse: i det øyeblikket du lager det nye objektet, tenker du allerede som en arkitekt, enten du mente det eller ikke. For hvert objekt du lager, er en forpliktelse. Det tar lagringsplass. Det får grenser. Det får en delingsmodell, enten du designet en eller ikke. Det trenger en lisens for alle som rører det. Og når folk og integrasjoner først er avhengige av det, lykke til med å fjerne det.
Så den første arkitekturbeslutningen er ikke hvilket objekt. Det er hvor bør disse dataene bo? Får du det riktig, velger objekttypen nesten seg selv.
På core og utenfor core
Section titled “På core og utenfor core ”Først et ord jeg kommer til å bruke mye: core. Core er Salesforce-plattformen orgen din kjører på: den metadatadrevne plattformen med mange leietakere fra modul 1, der salgs- og serviceobjektene fra modul 2 bor, og hvert egendefinert objekt du bygger i modul 3. Når jeg sier at data er på core (on core), mener jeg at de er lagret i orgen din, i objektene der.
Ikke alle data bor der. Data 360 holder dataene sine i sitt eget lager, utenfor orgens objekter (det er nær core (near-core): styrt på core, med dataene driftet utenfor core; mer i kapittel 4). Og så er det alt bedriften din kjører som ikke er Salesforce i det hele tatt: ERP-systemet, lageret, ordresystemet, partnerens plattform. Alt det er utenfor core (off core). Salesforce kan nå det, vise det og bruke det, men orgen din lagrer det ikke.
På core finnes det to typer objekter som faktisk holder postene dine: sObjects, standard og egendefinerte (__c), og big objects (__b). Utenfor core når du data gjennom eksterne objekter (__x) og de andre integrasjonsverktøyene. Ha suffiksene fra modul 3 i bakhodet; de forteller deg hvor en databit bor bare ut fra navnet.
Jeg tenker på det som et kontor. Noen ting hører hjemme på pulten din, der du bruker dem hver dag. Noen ting trenger du bare å slå opp i noen andres arkivskap. Og noen ting havner i esker i boden bak huset. Det gir meg tre svar.
1. På core: det bor på pulten din
Section titled “1. På core: det bor på pulten din ”Dataene opprettes, endres og brukes i Salesforce hver dag: kontoer, saker, salgsmuligheter, arbeidsordrer. Å holde dem i sObjects er som å ha dem fremst på kontoret. Det er dette standardobjekter og egendefinerte objekter er til for, og du får alt: sideoppsett, deling, automatisering, rapportering, søk og nå KI-funksjonene som er bygd på datamodellen.
Pulten din er likevel ikke gratis. Data på core koster lagringsplass, telt slik Salesforce teller, post for post, ikke kolonne for kolonne, og dokumenter teller for seg mot fillagringen. Vi dekket begge deler i modul 2. Store mengder bilder og skanninger hører ofte hjemme utenfor core, mens Salesforce bare beholder en lenke.
2. Referert: det bor i noen andres arkivskap
Section titled “2. Referert: det bor i noen andres arkivskap ”Dataene tilhører et annet system (ERP-systemet, et datavarehus, en ordreplattform), og det systemet forblir sannhetskilden. Brukerne må se dem i Salesforce, kanskje relatere dem til en post, men Salesforce trenger ikke sin egen kopi. Du hører også dette kalt virtuelle data: de dukker opp i Salesforce virtuelt, uten noen gang å bli lagret der.
Det er eksterne objekter, gjennom Salesforce Connect. Jeg pleier å si at det ser ut som en and og går som en and, men det er ikke en and. Det dukker opp som et sObject: du kan legge det på sideoppsett og relaterte lister, og relatere det til dine egne poster med eksterne og indirekte lookup-relasjoner. Men dataene lagres ikke på core. Hver gang du rører dem, gjøres et kall ut (callout). Åpne en post, last en relatert liste, kjør en rapport, og Salesforce går og spør det andre systemet. Det betyr ventetid, og siden din er bare så tilgjengelig som systemet bak den.
Folk protesterer på lisenskostnaden, så regn på det slik jeg gjør på kurset. Connect lisensieres per endepunkt, og ett endepunkt kan hente inn mange objekter. Spør deg så hva det koster å bygge og vedlikeholde alternativet: en egendefinert komponent, koden for kallet bak den, og en utvikler i beredskap når det ryker. Ofte er lisensen billigere, og adminene dine kan konfigurere det uten å skrive en eneste kodelinje. Der det faller gjennom: data brukerne redigerer hele dagen, eller rapporterer mye på.
Dokumenter kan også refereres. Ligger en kontrakt allerede i SharePoint Online, OneDrive, Google Drive eller Box, lar Files Connect brukerne nå den fra Salesforce uten å kopiere den inn.
Salesforce Connect er ikke den eneste måten å referere data på. Noen ganger er det egendefinert logikk: kode som kaller det andre systemet i sanntid og viser dataene på siden, uten at noen kopi beholdes. Det gir deg full kontroll, og fullt ansvar for kallet, feilene og vedlikeholdet. Og Data 360 kan også føderere uten å kopiere. Det valget har sitt eget kapittel (Virtualisering, føderering og Zero-Copy). Her er poenget selve beslutningen: referer, ikke kopier.
3. Arkivert: det havner i boden bak huset
Section titled “3. Arkivert: det havner i boden bak huset ”Historikk, revisjonsspor, gamle transaksjoner. Du må ta vare på dem, noen ganger i årevis, men nesten ingen åpner dem. Og det er dette teamene utsetter. Når en klasse forteller meg at de har et objekt med 50 millioner poster og spør hvorfor de skulle arkivere, spør jeg tilbake: hvis du ikke arkiverer i dag, kommer du noen gang til å arkivere? Med 50 millioner i dag er du på vei mot 100, 150, 200 millioner.
Det finnes to boder. Den ene er på core: big objects. Tenk på dem som å lagre data i garasjen. Du kan lagre et enormt antall poster, men du kan ikke legge dem på et sideoppsett, det finnes ikke noe standard brukergrensesnitt eller rapportering, og du spør gjennom indeksen til big objectet, med eksakt treff eller intervall (Big Objects Best Practices (opens in a new tab)). Sikkerheten er bare objekt- og felttillatelser, uten deling av poster, og automatisering kjører ikke på dem. Jeg har brukt Salesforce Connect dusinvis av ganger og big objects bare én eller to ganger. De fungerer, men de er klønete, og jeg har skrevet min andel av omveier for å komme til dataene. Så mitt råd: lag en prototyp før du foreslår det, og planlegg hvordan folk skal finne dataene før du velger det.
Den andre boden er utenfor core: et datavarehus eller en database et annet sted (Design for skala). Ofte er det den beste boden, og den trenger ikke være ute av syne. Arkiverte data utenfor core kan fortsatt dukke opp i rapporter gjennom verktøy som Tableau, og de kan fortsatt nås fra Salesforce, gjennom Salesforce Connect eller en annen måte å virtualisere dem på, når noen trenger å se bakover.
La meg fortelle om et prosjekt der vi fikk dette riktig fra starten. En detaljhandelskunde hadde over 1 200 lokasjoner. De sa til meg: «Vi har bare hundre avtaler om dagen i en butikk. Ikke noe stort.» Så regnet jeg: hundre om dagen, seks dager i uka (omtrent 305 dager i året), på tvers av 1 200 lokasjoner, er over 36 millioner avtaler i året. Så nevnte de at hvert besøk skapte to avtaler, én ved skranken og én for verkstedet bak: over 73 millioner poster i året. Så ville de ha fem års historikk: mer enn 360 millioner poster, før noen vekst. Vi hadde ikke gått live, og jeg kunne allerede se toget dundre rett mot stasjonen for store datavolumer. Så arkivet ble bygd før vi samlet inn en eneste avtale: eldre avtaler ble flyttet til big objects, og søkeskjermen viste gjeldende avtaler med de arkiverte rett under. År senere går det fortsatt fint.
Slik brukes det: Steve Trucking
Section titled “Slik brukes det: Steve Trucking ”Steve Trucking er det gjennomgående scenarioet vårt: et familieeid budfirma for siste ledd (last mile) som henter hvitevarer og elektronikk på de store kjedenes distribusjonssentre, og så leverer og installerer dem hjemme hos kundene. Fire typer data, tre svar:
| Data | Hvor de bor | Hvorfor |
|---|---|---|
| Dagens leveringer, team og avtaler | På core | Disponenter og team jobber i dem hele dagen |
| Ordredetaljene til detaljhandelspartneren | Referert (eller en tynn kopi på core) | Detaljhandelspartnerens system er sannhetskilden |
| Leveringshistorikk fra tre år tilbake | Arkivert | Tatt vare på for reklamasjoner og trender; nesten ingen åpner den |
| Leveringsbilder | Utenfor core, lenket | Tusenvis om dagen; lagret utenfor Salesforce med en lenke på leveringen |
Her er det samme som en datamodell. Leveringen (Delivery) sitter på core, der folk jobber i den hele dagen. Etter tre år flyttes den til Delivery History, et big object: fortsatt på core, men ute i boden. Partnerens ordre dukker opp som et eksternt objekt, __x: Salesforce relaterer leveringen til den, men dataene blir i detaljhandelspartnerens system. Og bildene bor helt utenfor core, med en lenke fra leveringen. Én modell, tre hjem.
Hver ekte org har alle tre. De som får problemer, legger alt på core, fordi det å lage et objekt var standardknappen.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hjemmet for hver type data, før noe objekt designes: på core, referert eller arkivert.
- Sannhetskilden. Eier et annet system dataene, skal ikke Salesforce i det stille bli en annen master.
- Tilgangsveien for alt utenfor core. Refererte data trenger en tilgjengelig kilde og akseptabel ventetid; arkiverte data trenger en måte folk kan finne dem på.
- Lagringsvekst. Regn på det nå (poster per dag, ganger vekst, ganger oppbevaringstid), ikke når lagringsvarselet kommer.
Utover eksamen: KI øker innsatsen for «på core». KI-funksjoner og agenter fungerer best på data plattformen forstår: data i standardobjekter og egendefinerte objekter, godt navngitt og godt beskrevet. Det trekker mot å legge mer på core. Motstå det for feil data. En agent forankret i en utdatert kopi av ERP-data gir selvsikre, gale svar. Ofte er det bedre å referere den levende kilden, eller å holde en liten, godt beskrevet del på core. Hvor KI leser dataene, er nå en del av å bestemme hvor dataene bor.
Les mer
Section titled “Les mer ”- Big Objects Best Practices (opens in a new tab), Salesforce Developers (på engelsk, kontrollert 2026-09-25)
- Files Connect FAQ (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-09-25)
- I dette kurset: Virtualisering, føderering og Zero-Copy og Design for skala