Elke structuur is een verplichting
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Hoofdstuk 3 van Data Architect, Deel 1: Data-architect worden. Vorige: Data modelleren naar betekenis.
Dit is een vraag die ik elke klas stel. Als iemand zegt “ik werk met Salesforce”, wat is dan de API-naam van het productobject?
Het is Product2. Het is mijn eerste lakmoesproef. Ergens onderweg bouwde Salesforce het productobject, merkte dat het niet werkte, en moest het achterlaten. Ze konden het niet zomaar weghalen, dus voegden ze Product2 toe. Zelfs Salesforce leeft met zijn oude structuren.
Salesforce gaf zichzelf ook ruimte om te groeien. Zijn standaardobjecten hebben geen voor- of achtervoegsel, en wij, de mensen die orgs aanpassen, kunnen die ruimte nooit innemen. Dus kan Salesforce objecten blijven toevoegen zonder ooit te botsen met iets wat wij bouwen.
De les daarin: een object maken kost tien minuten. Ermee leven kost jaren. Elk object en elk veld dat je toevoegt is een verplichting. Het neemt opslag in. Het krijgt limieten. Het krijgt een sharingmodel, of je er nu een ontwierp of niet. Het heeft een licentie nodig voor iedereen die het aanraakt. En nu leest AI het ook, dus hoe je het noemt en hoe je het beschrijft bepaalt wat een agent van je data begrijpt. Toevoegen is makkelijk. Weghalen is moeilijk.
Dit hoofdstuk maakt van de bouwstenen van Salesforce beslissingen.
Afbeelding gegenereerd met AI.
De structuren in één oogopslag
Section titled “De structuren in één oogopslag ”Salesforce geeft je zes plekken om data in te bewaren. Ik zet ze op één slide, want de eerste taak is weten dat ze allemaal bestaan:
| Structuur | Waar het voor is | Het addertje |
|---|---|---|
| Standaardobjecten | Het eigen model van Salesforce: account, contactpersoon, verkoopkans, case, asset en de rest | Gebruik ze waarvoor ze bedoeld zijn, anders werken ze tegen |
| Aangepaste objecten | Je eigen bedrijfsdata | Makkelijk te maken, moeilijk uit te faseren |
| Externe objecten | Data die in een ander systeem staat en in Salesforce getoond wordt | Elke aanraking is een callout |
| Big objects | Enorme volumes die je moet bewaren maar zelden opent | Geen standaard-UI of rapportage; je bevraagt ze via de index |
| Files | Documenten, foto’s en andere content | De bestandsopslag loopt snel op |
| Attachments | De oude manier om bestanden op te slaan | Verouderd: gebruik Files |
Er een kiezen is maar een deel ervan. Vóór de structuur komt de vraag waar de data überhaupt hoort: in de core, verwezen waar die al staat, of gearchiveerd.
De route door dit hoofdstuk
Section titled “De route door dit hoofdstuk ”Dit hoofdstuk is groot, dus het komt in tien delen. Elk deel staat op zichzelf. In hoofdstuk 2 besloten we wat het model moet zijn; hier besluiten we hoe het op Salesforce moet leven.
- Het Salesforce-dataplatform: meer dan een database. Wat Salesforce anders maakt, en waarom het platform een vorm heeft.
- Kijk naar het moederschip: de standaard datamodellen. De sales- en servicemodellen die Salesforce al gebouwd heeft, bestanden, opslag en persoonsaccounts.
- Bouw je eigen: aangepaste objecten. Wat het scherm New Custom Object beslist, de velden die je niet zelf hebt gemaakt, en hoe je elke API-naam leest: standaard, aangepast of managed package.
- Waar staan deze gegevens? In de core, verwezen of gearchiveerd, beslist voordat er een object wordt gemaakt.
- Kies het juiste object. De schone-fit-test, de bagage die standaardobjecten meebrengen, persoonsaccounts, en de licenties die bepalen wat mensen kunnen gebruiken.
- Velden zijn ook architectuur. Veldtype voor veldtype, het gedrag dat mensen verrast, en waarom elk veld een omschrijving krijgt.
- Relaties hebben gevolgen. Lookup of master-detail, drie niveaus diep en twee parents breed, het logische koppelobject en het Salesforce-koppelobject (Salesforce Junction Object), en de limieten die bijten.
- Eigenaarschap en levenscyclus. Wie eigenaar is van een record, de share-tabel waar eigenaarschap toegang wordt, en wat er in zijn leven met een record gebeurt.
- Gegevens consistent houden. De consistentieladder: elke laag heeft een prijs, en je “repareert” de geschiedenis nooit om een nieuwe regel tevreden te stellen.
- Ontwerp het fysieke Salesforce-model. Een uitsnede van Steve Trucking, van logisch model naar Salesforce, stap voor stap opgebouwd, met de redenering.
Als je klaar bent, test jezelf met de studiegids bij dit hoofdstuk: een checklist voor het examen, de gewoonten die verder gaan, de begrippen en een paar vragen.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Wat Salesforce al modelleert, voordat je iets verzint: kijk naar het moederschip.
- Waar elk soort data hoort, in de core, verwezen of gearchiveerd, voordat er een structuur gekozen wordt.
- Welke structuur het bevat, in de wetenschap wat elke structuur inlevert.
- Hoe de objecten zich tot elkaar verhouden, wie eigenaar is van de records, en wat dat betekent voor toegang en schaal.
- Van welke licenties het model afhangt, gecontroleerd voordat de objecten ontworpen worden, niet erna.
- Hoe de data consistent blijft, en wat elke consistentielaag kost.
Voorbij het examen: met AI kun je in een paar minuten objecten en velden maken. Als toevoegen bijna gratis is, wordt “elke structuur is een verplichting” belangrijker, niet minder belangrijk. Elke module eindigt met wat AI voor die beslissing verandert.
Verder lezen
Section titled “Verder lezen ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (Engels)
- Standard User Licenses (opens in a new tab), Salesforce Help (Engels)
Volgende: Enterprisegegevens begrijpen