Varje struktur är ett åtagande
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)
Kapitel 3 i Data Architect, Del 1: Att bli dataarkitekt. Föregående: Modellera data för mening.
Här är en fråga jag ställer i varje klass. Om någon säger ”jag jobbar med Salesforce”, vad är API-namnet på produktobjektet?
Det är Product2. Det är mitt första lackmustest. Någonstans på vägen byggde Salesforce produktobjektet, insåg att det inte fungerade och fick lämna det bakom sig. De kunde inte bara ta bort det, så de lade till Product2. Till och med Salesforce lever med sina gamla strukturer.
Salesforce gav sig också utrymme att växa. Standardobjekten har inget prefix eller suffix, och vi, de som anpassar orgar, kan aldrig ta det utrymmet i anspråk. Så Salesforce kan fortsätta lägga till objekt utan att någonsin krocka med något vi bygger.
Här är lärdomen i det: att skapa ett objekt tar tio minuter. Att leva med det tar år. Varje objekt och varje fält du lägger till är ett åtagande. Det tar lagringsutrymme. Det drar på sig gränser. Det får en delningsmodell, oavsett om du har designat en eller inte. Det behöver en licens för varje person som rör det. Och nu läser AI det också, så vad du döper det till och hur du beskriver det avgör vad en agent förstår om dina data. Att lägga till är lätt. Att ta bort är svårt.
Det här kapitlet gör byggstenarna i Salesforce till beslut.
Bilden är genererad med AI.
Strukturerna i korthet
Section titled “Strukturerna i korthet ”Salesforce ger dig sex ställen att lagra data på. Jag lägger dem på en enda bild, för det första jobbet är att veta att alla finns:
| Struktur | Vad den är till för | Haken |
|---|---|---|
| Standardobjekt | Salesforce egen modell: konto (Account), kontakt (Contact), affärsmöjlighet (Opportunity), ärende (Case), tillgång (Asset) och resten | Använd dem till det de är avsedda för, annars kämpar de emot |
| Anpassade objekt | Dina egna affärsdata | Lätta att skapa, svåra att avveckla |
| Externa objekt | Data som bor i ett annat system och visas i Salesforce | Varje åtkomst är ett anrop ut (callout) |
| Big objects | Enorma volymer som du måste behålla men sällan öppnar | Inget standardgränssnitt eller rapportering; du frågar via indexet |
| Filer (Files) | Dokument, foton och annat innehåll | Fillagringen växer snabbt |
| Bilagor (Attachments) | Det gamla sättet att lagra filer | Föråldrat: använd Files |
Att välja en är bara en del av det. Före strukturen kommer frågan om var data alls ska bo: på core, refererade där de redan finns, eller arkiverade.
Vägen genom kapitlet
Section titled “Vägen genom kapitlet ”Det här kapitlet är stort, så det kommer i tio delar. Var och en står på egna ben. I kapitel 2 bestämde vi vad modellen ska vara; här bestämmer vi hur den ska leva i Salesforce.
- Dataplattformen i Salesforce: mer än en databas. Vad som gör Salesforce annorlunda, och varför plattformen har en form.
- Titta på moderskeppet: standarddatamodellerna. Säljmodellen och Servicemodellen som Salesforce redan har byggt, filer, lagring och personkonton.
- Bygg ditt eget: anpassade objekt. Vad skärmen New Custom Object bestämmer, fälten du inte skapade, och hur du läser vilket API-namn som helst: standard, anpassat eller hanterat paket (managed package).
- Var bor de här data? På core, refererade eller arkiverade, bestämt innan något objekt skapas.
- Välj rätt objekt. Testet för ren passform, bagaget som standardobjekt för med sig, personkonton, och licenserna som avgör vad människor kan använda.
- Fält är också arkitektur. Fälttyp för fälttyp, beteendena som överraskar folk, och varför varje fält får en beskrivning.
- Relationer får konsekvenser. Lookup eller master-detail, tre nivåer djupt och två föräldrar brett, det logiska kopplingsobjektet och kopplingsobjektet i Salesforce (Salesforce Junction Object), och gränserna som biter.
- Ägarskap och livscykel. Vem som äger en post, delningstabellen där ägarskap blir åtkomst, och vad som händer med en post under dess livstid.
- Håll data konsistenta. Konsistensstegen: varje lager har en kostnad, och du ”rättar” aldrig historiken för att uppfylla en ny regel.
- Designa den fysiska modellen i Salesforce. Ett utsnitt av Steve Trucking, från logisk modell till Salesforce, uppbyggt steg för steg, med resonemanget.
När du är klar kan du testa dig själv med kapitlets studieguide: en checklista inför provet, vanorna bortom det, orden att kunna och några frågor.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”- Vad Salesforce redan modellerar, innan du hittar på något: titta på moderskeppet.
- Var varje sorts data bor, på core, refererade eller arkiverade, innan du väljer en struktur.
- Vilken struktur som lagrar dem, med vetskap om vad var och en ger upp.
- Hur objekten hänger ihop, vem som äger posterna, och vad det betyder för åtkomst och skala.
- Vilka licenser modellen är beroende av, kontrollerat innan objekten designas, inte efteråt.
- Hur data hålls konsistenta, och vad varje konsistenslager kostar.
Bortom provet: AI-assisterat byggande kan skapa objekt och fält på några minuter. När det nästan är gratis att lägga till spelar ”varje struktur är ett åtagande” större roll, inte mindre. Varje modul avslutas med vad AI förändrar för just det beslutet.
Utforska vidare
Section titled “Utforska vidare ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (på engelska)
- Standard User Licenses (opens in a new tab), Salesforce Help (på engelska)
Nästa: Förstå företagets data