Hver struktur er en forpligtelse
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)
Kapitel 3 i Data Architect, Del 1: At blive dataarkitekt. Forrige: Modellér data for betydning.
Her er et spørgsmål, jeg stiller på hvert hold. Hvis nogen siger »jeg arbejder med Salesforce«, hvad er så API-navnet på produktobjektet?
Det er Product2. Det er min første lakmusprøve. Et sted undervejs byggede Salesforce produktobjektet, indså, at det ikke fungerede, og måtte lade det ligge. De kunne ikke bare fjerne det, så de tilføjede Product2. Selv Salesforce lever med sine gamle strukturer.
Salesforce gav også sig selv plads til at vokse. Standardobjekterne har intet præfiks eller suffiks, og vi, der tilpasser org’erne, kan aldrig tage den plads. Så Salesforce kan blive ved med at tilføje objekter og aldrig støde sammen med noget, vi bygger.
Her er læren i det: at oprette et objekt tager ti minutter. At leve med det tager år. Hvert objekt og hvert felt, du tilføjer, er en forpligtelse. Det optager lagerplads. Det samler grænser op. Det får en delingsmodel, uanset om du har designet en eller ej. Det kræver en licens til hver person, der rører det. Og nu læser AI det også, så hvad du kalder det, og hvordan du beskriver det, afgør, hvad en agent forstår om dine data. Det er nemt at tilføje. Det er svært at fjerne.
Dette kapitel gør Salesforces byggeklodser til beslutninger.
Billedet er genereret med AI.
Strukturerne i overblik
Sektion kaldt “Strukturerne i overblik ”Salesforce giver dig seks steder at gemme data. Jeg sætter dem på ét dias, for den første opgave er at vide, at de alle findes:
| Struktur | Hvad den er til | Hagen ved den |
|---|---|---|
| Standardobjekter | Salesforces egen model: konto (Account), kontakt (Contact), salgsmulighed (Opportunity), sag (Case), aktiv (Asset) og resten | Brug dem til det, de er beregnet til, ellers kæmper de imod dig |
| Brugerdefinerede objekter | Dine egne forretningsdata | Nemme at oprette, svære at pensionere |
| Eksterne objekter | Data, der bor i et andet system, vist i Salesforce | Hver berøring er et kald ud (callout) |
| Big objects | Enorme mængder, du skal beholde, men sjældent åbner | Ingen standardbrugerflade eller rapportering; du forespørger via indekset |
| Filer | Dokumenter, billeder og andet indhold | Fillagerforbruget stiger hurtigt |
| Vedhæftede filer (Attachments) | Den gamle måde at gemme filer på | Forældet: brug Filer (Files) |
At vælge én er kun en del af det. Før strukturen kommer spørgsmålet om, hvor dataene overhovedet skal bo: på core, refereret der, hvor de allerede ligger, eller arkiveret.
Vejen gennem kapitlet
Sektion kaldt “Vejen gennem kapitlet ”Dette kapitel er stort, så det kommer i ti dele. Hver del står på egne ben. I kapitel 2 besluttede vi, hvad modellen skal være; her beslutter vi, hvordan den skal leve i Salesforce.
- Salesforce-dataplatformen: mere end en database. Hvad der gør Salesforce anderledes, og hvorfor platformen har en form.
- Kig på moderskibet: standarddatamodellerne. Salgs- og servicemodellerne, som Salesforce allerede har bygget, filer, lagerplads og personkonti.
- Byg dit eget: brugerdefinerede objekter. Hvad skærmen New Custom Object beslutter, de felter, du ikke selv oprettede, og hvordan du læser ethvert API-navn: standard, brugerdefineret eller fra en administreret pakke.
- Hvor bor disse data? På core, refereret eller arkiveret, besluttet før der oprettes et eneste objekt.
- Vælg det rigtige objekt. Testen for et rent match, den bagage, standardobjekter har med, personkonti og de licenser, der afgør, hvad folk kan bruge.
- Felter er også arkitektur. Felttype for felttype, den adfærd, der overrasker folk, og hvorfor hvert felt får en beskrivelse.
- Relationer har konsekvenser. Lookup eller master-detail, tre niveauer i dybden og to forældre i bredden, det logiske forbindelsesobjekt og forbindelsesobjektet i Salesforce (Salesforce Junction Object), og de grænser, der bider.
- Ejerskab og livscyklus. Hvem der ejer en post, delingstabellen, hvor ejerskab bliver til adgang, og hvad der sker med en post i løbet af dens liv.
- Hold data konsistente. Konsistensstigen: hvert lag har en pris, og du »retter« aldrig historikken for at opfylde en ny regel.
- Design den fysiske model i Salesforce. Et udsnit af Steve Trucking, fra logisk model til Salesforce, bygget op trin for trin, med begrundelserne.
Når du er færdig, kan du teste dig selv med kapitlets studieguide: en tjekliste til eksamen, vanerne ud over den, de ord, du skal kende, og et par spørgsmål.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hvad Salesforce allerede modellerer, før du opfinder noget: kig på moderskibet.
- Hvor hver slags data bor, på core, refereret eller arkiveret, før du vælger en struktur.
- Hvilken struktur der rummer dem, med viden om, hvad hver af dem giver afkald på.
- Hvordan objekterne hænger sammen, hvem der ejer posterne, og hvad det betyder for adgang og skala.
- Hvilke licenser modellen afhænger af, tjekket før objekterne designes, ikke bagefter.
- Hvordan dataene forbliver konsistente, og hvad hvert konsistenslag koster.
Ud over eksamen: AI-assisteret byggeri kan oprette objekter og felter på få minutter. Når det næsten er gratis at tilføje, betyder »hver struktur er en forpligtelse« mere, ikke mindre. Hvert modul slutter med, hvad AI ændrer for den beslutning.
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (på engelsk)
- Standard User Licenses (opens in a new tab), Salesforce Help (på engelsk)
Næste: Forstå virksomhedens data