Hver struktur er en forpliktelse
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)
Kapittel 3 i Data Architect, Del 1: Å bli dataarkitekt. Forrige: Modeller data for mening.
Her er et spørsmål jeg stiller i hver klasse. Hvis noen sier «jeg jobber med Salesforce», hva er API-navnet på produktobjektet?
Det er Product2. Det er min første lakmustest. Et sted underveis bygde Salesforce produktobjektet, innså at det ikke fungerte, og måtte legge det bak seg. De kunne ikke bare fjerne det, så de la til Product2. Selv Salesforce lever med de gamle strukturene sine.
Salesforce ga seg også selv plass til å vokse. Standardobjektene har verken prefiks eller suffiks, og vi, som tilpasser orger, kan aldri ta det rommet i bruk. Så Salesforce kan fortsette å legge til objekter uten å kollidere med noe vi bygger.
Her er lærdommen i det: å opprette et objekt tar ti minutter. Å leve med det tar år. Hvert objekt og hvert felt du legger til, 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 hver person som rører det. Og nå leser KI (AI) det også, så hva du kaller det og hvordan du beskriver det, avgjør hva en agent forstår av dataene dine. Å legge til er lett. Å ta bort er vanskelig.
Dette kapitlet gjør byggeklossene i Salesforce om til beslutninger.
Bildet er generert med KI.
Strukturene i et overblikk
Section titled “Strukturene i et overblikk ”Salesforce gir deg seks steder å holde data. Jeg setter dem på ett lysbilde, fordi den første jobben er å vite at alle finnes:
| Struktur | Hva den er til for | Haken |
|---|---|---|
| Standardobjekter | Salesforces egen modell: konto (Account), kontakt (Contact), salgsmulighet (Opportunity), sak (Case), aktivum (Asset) og resten | Bruk dem til det de er ment for, ellers kjemper de imot |
| Egendefinerte objekter | Dine egne forretningsdata | Lette å opprette, vanskelige å pensjonere |
| Eksterne objekter | Data som bor i et annet system, vist i Salesforce | Hver berøring er et kall ut (callout) |
| Big objects | Enorme volumer du må beholde, men sjelden åpner | Ingen standard brukergrensesnitt eller rapportering; du spør via indeksen |
| Filer | Dokumenter, bilder og annet innhold | Fillagringen klatrer fort |
| Vedlegg (Attachments) | Den gamle måten å lagre filer på | Utgått: bruk Files |
Å velge én er bare en del av det. Før strukturen kommer spørsmålet om hvor dataene i det hele tatt skal bo: på core, referert der de allerede ligger, eller arkivert.
Veien gjennom kapitlet
Section titled “Veien gjennom kapitlet ”Dette kapitlet er stort, så det kommer i ti deler. Hver del står på egne ben. I kapittel 2 bestemte vi hva modellen skal være; her bestemmer vi hvordan den skal leve på Salesforce.
- Dataplattformen i Salesforce: mer enn en database. Hva som gjør Salesforce annerledes, og hvorfor plattformen har en form.
- Se til moderskipet: standarddatamodellene. Salgsmodellen og Servicemodellen som Salesforce allerede har bygget, filer, lagring og personkontoer.
- Bygg ditt eget: egendefinerte objekter. Hva skjermen New Custom Object bestemmer, feltene du ikke opprettet, og hvordan du leser et hvilket som helst API-navn: standard, egendefinert eller administrert pakke (managed package).
- Hvor bor disse dataene? På core, referert eller arkivert, bestemt før noe objekt opprettes.
- Velg riktig objekt. Testen for ren passform, bagasjen standardobjekter tar med seg, personkontoer og lisensene som avgjør hva folk kan bruke.
- Felt er også arkitektur. Felttype for felttype, oppførselen som overrasker folk, og hvorfor hvert felt får en beskrivelse.
- Relasjoner har konsekvenser. Lookup eller master-detail, tre nivåer dypt og to overordnede bredt, det logiske koblingsobjektet og koblingsobjektet i Salesforce (Salesforce Junction Object), og grensene som biter.
- Eierskap og livssyklus. Hvem som eier en post, delingstabellen der eierskap blir tilgang, og hva som skjer med en post gjennom livet.
- Hold data konsistente. Konsistensstigen: hvert lag har en kostnad, og du «retter» aldri historikk for å tilfredsstille en ny regel.
- Design den fysiske modellen i Salesforce. Et utsnitt av Steve Trucking, fra logisk modell til Salesforce, bygget opp steg for steg, med begrunnelsene.
Når du er ferdig, kan du teste deg selv med studieguiden for kapitlet: en sjekkliste til eksamen, vanene utover den, ordene du bør kunne og noen spørsmål.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hva Salesforce allerede modellerer, før du finner opp noe: se til moderskipet.
- Hvor hver type data bor, på core, referert eller arkivert, før du velger en struktur.
- Hvilken struktur som holder dataene, med kunnskap om hva hver av dem gir avkall på.
- Hvordan objektene henger sammen, hvem som eier postene, og hva det betyr for tilgang og skala.
- Hvilke lisenser modellen avhenger av, sjekket før objektene designes, ikke etterpå.
- Hvordan dataene holdes konsistente, og hva hvert konsistenslag koster.
Utover eksamen: KI-assistert bygging kan opprette objekter og felt på minutter. Når det nesten er gratis å legge til, betyr «hver struktur er en forpliktelse» mer, ikke mindre. Hver modul avsluttes med hva KI endrer for den beslutningen.
Les mer
Section titled “Les mer ”- 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)
Neste: Forstå virksomhetens data