Meer dan een database

🌐 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)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 1 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Volgende: Kijk naar het moederschip: de standaard datamodellen

De vraag die deze module beantwoordt: Wat maakt Salesforce anders dan een traditionele database?

Als je al een tijd Salesforce-admin bent, weet je al hoe je een object maakt. Setup, Object Manager, New Custom Object. Geef het een naam, voeg een paar velden toe, bouw een page layout, en tien minuten later kunnen gebruikers ermee werken.

Maar wat gebeurde er eigenlijk toen je op Save klikte?

Als je een databaseachtergrond hebt, stel je je waarschijnlijk voor dat Salesforce een nieuwe tabel aanmaakte. Dat deed het niet. En begrijpen waarom is een van de plekken waar je verschuift van denken als een admin of developer naar denken als een architect.

Salesforce slaat natuurlijk data op; eronder zitten databases. Maar Salesforce is geen database met een mooi scherm erop. Het is een metadatagestuurd applicatieplatform, en dat onderscheid bepaalt bijna elke beslissing in deze cursus.

Het platform heeft een vorm

In hoofdstuk 2 bouwden we het model zonder ons ook maar iets van Salesforce aan te trekken. Dat was met opzet: we luisterden naar de zelfstandige naamwoorden, bouwden het conceptuele model, voegden attributen, sleutels en relaties toe, en vroegen pas daarna hoe Salesforce het moest implementeren. Nu moeten we het ding begrijpen waarop we het implementeren.

Ik gebruik hier een simpele zin voor: het platform heeft een vorm. Salesforce geeft ons objecten, velden, relaties, beveiliging, automatisering, API’s, transacties, rapportage en zoeken, en die hangen allemaal samen. Als ik een object maak, maak ik niet alleen een plek om rijen in te zetten. Ik maak iets dat deelneemt aan het beveiligingsmodel, waar automatisering op kan werken, dat de API’s beschikbaar stellen, dat rapporten kunnen gebruiken, waar andere objecten aan kunnen relateren, en waar gebruikers, integraties en, steeds vaker, agents van gaan afhangen. Dat is veel meer dan een tabel.

Metadata is de bouwtekening

Denk aan een gebouw. Er is het gebouw zelf, en er is de bouwtekening die het beschrijft: waar de muren staan, waar de deuren komen, hoe de ruimtes met elkaar verbonden zijn. Salesforce werkt net zo. Een objectdefinitie is metadata. Een velddefinitie is metadata. Een relatie is metadata. Het meeste wat we in Setup configureren is metadata, en het platform leest die tijdens runtime om onze org zijn structuur en gedrag te geven.

Salesforce beschrijft het hart van het platform als zowel multitenant als metadatagestuurd: als we een object of veld definiëren, wordt de definitie als metadata opgeslagen, niet als een nieuwe fysieke tabel of kolom voor onze org (Platform Multitenant Architecture (opens in a new tab), Engels).

Als ik dit lesgeef, doe ik de motorkap open. Salesforce maakt niet elke keer een nieuwe database voor je als je een object toevoegt. Het voegt een record toe aan zijn eigen tabellen: een tabel met objecten, een tabel met velden, een tabel met data, en draaitabellen voor indexen en relaties, allemaal gesleuteld op een org-identificator die de data van jouw org gescheiden houdt van die van iedereen. Een veld toevoegen is dus gewoon een regel toevoegen. Daarom kun je er een maken terwijl je bezig bent, in de lunchpauze, in productie.

Het verklaart ook iets waar mensen over struikelen. Als je SELECT Id, Name, Special__c FROM Account schrijft, lijkt het één tabel. Eronder lees je het standaardobject en zijn aangepaste veld uit verschillende structuren, dus het platform doet een join die je nooit geschreven hebt. Indexen bestaan, maar ze werken niet zoals een index in een traditionele database. Voor het examen hoef je de interne werking niet te kennen. Wel moet je weten dat wat je in Object Manager ziet geen een-op-een-afbeelding van fysieke tabellen is, en dat de abstractie zowel de kracht van het platform is als de reden waarom het zich gedraagt zoals het doet.

Click to enlarge

Kijk naar het moederschip

Een van de dingen die ik mensen in de klas vertel, is kijk naar het moederschip. Voordat je een ingewikkelde manier bedenkt om iets op Salesforce te doen, kijk hoe Salesforce het zelf doet.

Neem Account. Jij hebt het niet gemaakt; Salesforce wel. Maar je kunt er velden aan toevoegen, er automatisering omheen bouwen, de layouts veranderen, het via de API’s beschikbaar stellen en andere objecten eraan relateren. Aangepaste objecten draaien op hetzelfde mechaniek, en daarom voelen standaard- en aangepaste objecten zo vergelijkbaar als we erop bouwen. In Apex delen ze zelfs een basisklasse, het sObject.

Dat is de gewoonte waarop dit hoofdstuk voortbouwt, en in de volgende module kijken we goed: naar de standaard datamodellen die Salesforce al voor je gebouwd heeft.

We bouwen niet naast Salesforce. We breiden het uit.

Je API kwam mee met het object

Maak een tabel in een traditionele database en je hebt een tabel. Als een andere applicatie ermee moet werken, heeft iemand meer werk te doen. Maak een object op Salesforce, en het platform begrijpt het al via zijn applicatie- en integratielagen: het gebruikt dezelfde metadata om zijn REST- en SOAP-API’s te leveren, dus de records van het object kunnen daarmee worden aangemaakt, gelezen, bijgewerkt en verwijderd zodra het object bestaat (Platform Multitenant Architecture (opens in a new tab), Engels).

Ik heb geen API ontworpen omdat ik een object maakte. Het platform kent het object, zijn velden, hun typen, zijn relaties en zijn beveiliging. Dat is een van de redenen waarom ontwikkelen op Salesforce zo snel gaat. Het is ook waarom een object maken een grotere beslissing is dan het lijkt: je sluit een structuur aan op een compleet applicatieplatform. En het werkt ook andersom. Mensen die van SQL Server of Oracle komen, vragen me soms hoe ze data rechtstreeks in de database laden. Dat kan niet. Alles komt binnen via de API’s.

Het appartementengebouw

Nu het woord dat je steeds hoort: multitenancy. Ik zie het als een appartementengebouw.

Je hebt je eigen appartement. Je meubels zijn van jou, en jouw sleutel hoort mijn deur niet te openen. Maar we delen het gebouw: de stroom, het water, de liften, de hal. Je org voelt als je eigen omgeving, met je eigen data, objecten en automatisering. Eronder beschrijft Salesforce elke org als een tenant, waarbij de data, metadata en logica van elke tenant afgeschermd zijn terwijl de infrastructuur en diensten gedeeld worden (Platform Multitenant Architecture (opens in a new tab), Engels). Zo kan het elke klant zo’n aanpasbaar platform geven zonder voor ieder een aparte stack te draaien.

Maar het gebouw delen heeft gevolgen. Als één bewoner een enorme airco koopt en tegelijk de föhn en de oven aanzet, slaan de stoppen door, en zit de hele verdieping in het donker.

Je kunt de lift niet overnemen

Blijf nog even in het gebouw. Stel dat één bewoner aankondigt: “Ik heb de lift nodig van acht tot twaalf. Niemand anders mag hem gebruiken.” Dat werkt niet in een gedeeld gebouw, en op Salesforce ook niet. Eén tenant mag niet onbeperkt gedeelde middelen verbruiken en het platform voor iedereen slechter maken.

Daar komen governor limits vandaan. Als je op Salesforce hebt ontwikkeld, heb je ze waarschijnlijk leren kennen als een lijst getallen om uit je hoofd te leren. Zo wil ik niet dat je erover denkt. Salesforce past limieten toe op transactie- en orgniveau, zodat de werklast van één tenant de gedeelde rekenkracht niet opeist (Architecture Basics (opens in a new tab), Engels). Dat is de architectuur; elke afzonderlijke limiet is daar alleen de uitvoering van. Later in de cursus geven we om bepaalde limieten omdat ze een ontwerp veranderen. Onthoud voor nu het gebouw: je hebt enorm veel vrijheid om je appartement te verbouwen. Je mag de lift niet overnemen.

Salesforce-ID’s horen bij de abstractie

Elk Salesforce-record heeft een identiteit die het platform begrijpt, de record-ID, en die werkt in elke mogelijkheid: de UI, de API’s, rapporten, automatisering.

In hoofdstuk 2 zeiden we dat een goede sleutel uniek, onveranderlijk, betekenisloos en nooit persoonsgegevens is. De Salesforce-ID voldoet daaraan voor Salesforce. Maar het is niet hetzelfde als een bedrijfssleutel. Je bedrijf heeft misschien nog steeds een klantnummer uit het ERP, een personeelsnummer of het ordernummer van een partner dat over systemen heen iets betekent. Verwar “Salesforce weet welk record dit is” niet met “de organisatie weet welk bedrijfsding dit is”. Dat zijn verschillende identiteitsproblemen, en het tweede komt terug bij integratie en stamgegevens.

Objecten zijn meer dan opslag

Dit is de verschuiving die ik je wil laten maken vóór de rest van dit hoofdstuk. Een object is niet alleen een plek om data op te slaan. Een veld is niet alleen een kolom, en een relatie is niet alleen een foreign key. Ik gebruik de databasevergelijkingen als ik lesgeef, omdat ze aansluiten op wat mensen al weten. Maar als we daar ophouden, missen we de architectuur.

Het object dat we kiezen bepaalt welke mogelijkheden erbij horen. Het veldtype beïnvloedt validatie, integratie, zoeken, rapportage en hoe andere systemen de data lezen. De relatie bepaalt levenscyclus, eigenaarschap, sharing en verwijdering. Waar we de data zetten beïnvloedt opslag, prestaties en schaal. En omdat dit allemaal op een gedeeld platform draait, kan een keuze die met honderd records onschuldig is zich met honderd miljoen heel anders gedragen. We nemen die beslissingen een voor een.

Voorbij het examen: wat AI verandert. Jarenlang hielpen goede namen en omschrijvingen de volgende admin of developer te begrijpen wat we bouwden. Nu lezen machines die context ook. Een AI-systeem dat werkt met een veld dat Flag2__c heet, heeft hetzelfde probleem als een nieuwe developer: wat betekent dit ding? Metadata is geen versiering meer; het is deel van hoe machines de applicatie begrijpen.

Wat een architect hier beslist

• Ontwerp ik voor het platform waar ik echt op zit, of behandel ik Salesforce als een generieke database?
• Welke delen van mijn ontwerp zijn bedrijfsconcepten, en welke zijn implementatiekeuzes in Salesforce?
• Welk platformgedrag komt mee met de structuur die ik ga maken?
• Welke limieten zijn uitingen van de gedeelde architectuur, en welke ervan gaan dit ontwerp vormen?
• Als deze structuur later moeilijk te veranderen wordt, behandel ik haar dan als een architectuurbeslissing?

In hoofdstuk 2 zeiden we: ontwerp niet vanuit Setup. Nu ken je nog een reden. Op New Custom Object klikken geeft je niet alleen een tabel; het verbindt nog een stuk van je architectuur met een metadatagestuurd, multitenant platform. Maar voordat je beslist welk object je maakt, is er een fundamentelere vraag: horen deze gegevens hier überhaupt? Dat is de volgende.

Verder lezen

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (Engels), gecontroleerd op 2026-10-02, opnieuw gecontroleerd op 2026-10-12: object- en velddefinities worden opgeslagen als metadata, niet als nieuwe tabellen; gedeelde tabellen (MT_Objects, MT_Fields, MT_Data, MT_Indexes) met OrgID als sleutel; dezelfde metadata levert de REST- en SOAP-API’s.
• Salesforce Architects, Architecture Basics (opens in a new tab) (Engels), gecontroleerd op 2026-10-02, opnieuw gecontroleerd op 2026-10-12: governor- en uitvoeringslimieten zodat code en transacties “don’t monopolize shared compute resources” (gedeelde rekenkracht niet monopoliseren).