Mehr als eine Datenbank

🌐 Auch in 28 Sprachen

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 1 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Weiter: Schauen Sie aufs Mutterschiff: die Standarddatenmodelle

Die Frage, die dieses Modul beantwortet: Was unterscheidet Salesforce von einer klassischen Datenbank?

Wenn Sie schon eine Weile in der Salesforce-Administration arbeiten, wissen Sie, wie man ein Objekt erstellt. Setup, Objekt-Manager, Neues benutzerdefiniertes Objekt. Einen Namen vergeben, ein paar Felder hinzufügen, ein Seitenlayout bauen, und zehn Minuten später können die Benutzer damit arbeiten.

Aber was ist eigentlich passiert, als Sie auf Speichern geklickt haben?

Wenn Sie aus der Datenbankwelt kommen, stellen Sie sich wahrscheinlich vor, Salesforce habe eine neue Tabelle angelegt. Hat es nicht. Und zu verstehen, warum, ist eine der Stellen, an denen Sie beginnen, vom Denken in Administration oder Entwicklung zum Denken in Architektur zu wechseln.

Salesforce speichert natürlich Daten; darunter liegen Datenbanken. Aber Salesforce ist keine Datenbank mit einer hübschen Oberfläche. Es ist eine metadatengesteuerte Anwendungsplattform, und dieser Unterschied prägt fast jede Entscheidung in diesem Kurs.

Die Plattform hat eine Form

In Kapitel 2 haben wir das Modell gebaut, ohne uns um Salesforce zu kümmern. Das war Absicht: Wir haben auf die Substantive gehört, das konzeptionelle Modell gebaut, Attribute, Schlüssel und Beziehungen hinzugefügt und erst dann gefragt, wie Salesforce es umsetzen soll. Jetzt müssen wir das verstehen, worauf wir es umsetzen.

Dafür verwende ich einen einfachen Satz: Die Plattform hat eine Form. Salesforce gibt uns Objekte, Felder, Beziehungen, Sicherheit, Automatisierung, APIs, Transaktionen, Berichte und Suche, und alles ist miteinander verbunden. Wenn ich ein Objekt erstelle, schaffe ich nicht nur einen Ort für Zeilen. Ich schaffe etwas, das am Sicherheitsmodell teilnimmt, auf das Automatisierung wirken kann, das die APIs bereitstellen, das Berichte nutzen können, mit dem andere Objekte verknüpft werden können und von dem Benutzer, Integrationen und zunehmend Agenten abhängen werden. Das ist weit mehr als eine Tabelle.

Metadaten sind der Bauplan

Denken Sie an ein Gebäude. Da ist das Gebäude selbst, und da ist der Bauplan, der es beschreibt: wo die Wände sind, wo die Türen hinkommen, wie die Räume verbunden sind. Salesforce funktioniert genauso. Eine Objektdefinition ist Metadaten. Eine Felddefinition ist Metadaten. Eine Beziehung ist Metadaten. Das meiste, was wir im Setup konfigurieren, sind Metadaten, und die Plattform liest sie zur Laufzeit, um unserer Org ihre Struktur und ihr Verhalten zu geben.

Salesforce beschreibt das Herz der Plattform als sowohl mandantenfähig als auch metadatengesteuert: Wenn wir ein Objekt oder ein Feld definieren, wird die Definition als Metadaten gespeichert, nicht als neue physische Tabelle oder Spalte für unsere Org (Platform Multitenant Architecture (opens in a new tab), auf Englisch).

Wenn ich das unterrichte, schaue ich unter die Motorhaube. Salesforce erstellt nicht jedes Mal eine neue Datenbank für Sie, wenn Sie ein Objekt hinzufügen. Es fügt einen Datensatz in seine eigenen Tabellen ein: eine Tabelle der Objekte, eine Tabelle der Felder, eine Tabelle der Daten und Pivot-Tabellen für Indizes und Beziehungen, alle mit einer Org-Kennung verschlüsselt, die die Daten Ihrer Org von denen aller anderen trennt. Ein Feld hinzuzufügen heisst also nur, einen Eintrag hinzuzufügen. Deshalb können Sie eines spontan anlegen, in der Mittagspause, in der Produktion.

Es erklärt auch etwas, worüber Menschen stolpern. Wenn Sie SELECT Id, Name, Special__c FROM Account schreiben, sieht das aus wie eine Tabelle. Darunter lesen Sie das Standardobjekt und sein benutzerdefiniertes Feld aus verschiedenen Strukturen, also führt die Plattform einen Join aus, den Sie nie geschrieben haben. Es gibt Indizes, aber sie funktionieren nicht wie der Index einer klassischen Datenbank. Für die Prüfung müssen Sie die Interna nicht kennen. Sie müssen aber wissen, dass das, was Sie im Objekt-Manager sehen, kein Eins-zu-eins-Abbild physischer Tabellen ist, und dass diese Abstraktion sowohl die Stärke der Plattform als auch der Grund für ihr Verhalten ist.

Click to enlarge

Schauen Sie aufs Mutterschiff

Im Kurs sage ich den Leuten unter anderem: Schauen Sie aufs Mutterschiff. Bevor Sie einen komplizierten Weg erfinden, etwas auf Salesforce zu tun, schauen Sie, wie Salesforce selbst es tut.

Nehmen Sie den Account. Sie haben ihn nicht erstellt; Salesforce hat es. Aber Sie können Felder hinzufügen, darum herum automatisieren, seine Layouts ändern, ihn über die APIs bereitstellen und andere Objekte mit ihm verknüpfen. Benutzerdefinierte Objekte laufen auf derselben Maschinerie, deshalb fühlen sich Standard- und benutzerdefinierte Objekte beim Bauen so ähnlich an. In Apex teilen sie sogar eine Basisklasse, das sObject.

Auf dieser Gewohnheit baut dieses Kapitel auf, und im nächsten Modul schauen wir genau hin: auf die Standarddatenmodelle, die Salesforce bereits für Sie gebaut hat.

Wir bauen nicht neben Salesforce. Wir erweitern es.

Ihre API kam mit dem Objekt

Legen Sie in einer klassischen Datenbank eine Tabelle an, haben Sie eine Tabelle. Wenn eine andere Anwendung damit arbeiten muss, hat jemand mehr Arbeit. Erstellen Sie ein Objekt auf Salesforce, versteht die Plattform es bereits über ihre Anwendungs- und Integrationsschichten: Sie nutzt dieselben Metadaten, um ihre REST- und SOAP-APIs bereitzustellen, sodass die Datensätze des Objekts darüber erstellt, gelesen, aktualisiert und gelöscht werden können, sobald das Objekt existiert (Platform Multitenant Architecture (opens in a new tab), auf Englisch).

Ich habe keine API entworfen, weil ich ein Objekt erstellt habe. Die Plattform kennt das Objekt, seine Felder, ihre Typen, seine Beziehungen und seine Sicherheit. Das ist ein Grund, warum Salesforce-Entwicklung so schnell geht. Es ist auch der Grund, warum das Erstellen eines Objekts eine grössere Entscheidung ist, als es aussieht: Sie stecken eine Struktur in eine ganze Anwendungsplattform. Und es gilt auch umgekehrt. Leute aus der SQL-Server- oder Oracle-Welt fragen mich manchmal, wie man Daten direkt in die Datenbank lädt. Das geht nicht. Alles kommt über die APIs.

Das Mehrfamilienhaus

Jetzt das Wort, das Sie ständig hören: Mandantenfähigkeit (Multitenancy). Ich stelle sie mir als Mehrfamilienhaus vor.

Sie haben Ihre Wohnung. Ihre Möbel gehören Ihnen, und Ihr Schlüssel sollte meine Tür nicht öffnen. Aber wir teilen uns das Haus: den Strom, das Wasser, die Aufzüge, das Foyer. Ihre Org fühlt sich wie Ihre eigene Umgebung an, mit Ihren Daten, Ihren Objekten, Ihrer Automatisierung. Darunter beschreibt Salesforce jede Org als Mandanten und isoliert die Daten, Metadaten und Logik jedes Mandanten, während Infrastruktur und Dienste geteilt werden (Platform Multitenant Architecture (opens in a new tab), auf Englisch). So kann es jedem Kunden eine so anpassbare Plattform bieten, ohne für jeden einen eigenen Stack zu betreiben.

Aber das Haus zu teilen hat Folgen. Wenn ein Mieter eine riesige Klimaanlage kauft und gleichzeitig Föhn und Backofen laufen lässt, fliegt die Sicherung raus, und das ganze Stockwerk sitzt im Dunkeln.

Sie können den Aufzug nicht in Beschlag nehmen

Bleiben Sie noch einen Moment im Haus. Stellen Sie sich vor, ein Bewohner verkündet: «Ich brauche den Aufzug von acht bis zwölf. Niemand sonst darf ihn benutzen.» Das funktioniert in einem gemeinsamen Haus nicht, und auf Salesforce auch nicht. Ein Mandant darf gemeinsame Ressourcen nicht unbegrenzt verbrauchen und die Plattform für alle anderen verschlechtern.

Daher kommen die Governor-Limits. Wenn Sie auf Salesforce entwickelt haben, sind sie Ihnen wahrscheinlich als Liste auswendig zu lernender Zahlen begegnet. So sollen Sie nicht darüber denken. Salesforce wendet Grenzen auf Transaktions- und Org-Ebene an, damit die Arbeitslast eines Mandanten die gemeinsame Rechenleistung nicht monopolisiert (Architecture Basics (opens in a new tab), auf Englisch). Das ist die Architektur; jede einzelne Grenze ist nur ihre Umsetzung. Später im Kurs interessieren uns bestimmte Grenzen, weil sie einen Entwurf verändern. Merken Sie sich vorerst das Haus: Sie haben enorme Freiheit, Ihre Wohnung umzubauen. Den Aufzug dürfen Sie nicht in Beschlag nehmen.

Salesforce-IDs sind Teil der Abstraktion

Jeder Salesforce-Datensatz hat eine Identität, die die Plattform versteht, die Datensatz-ID, und sie funktioniert in jeder Funktion: der Oberfläche, den APIs, Berichten, der Automatisierung.

In Kapitel 2 haben wir gesagt, ein guter Schlüssel ist eindeutig, unveränderlich, bedeutungslos und niemals personenbezogen. Die Salesforce-ID erfüllt das für Salesforce. Aber sie ist nicht dasselbe wie ein Geschäftsschlüssel. Ihr Unternehmen hat vielleicht trotzdem eine ERP-Kundennummer, eine Personalnummer oder die Auftragsnummer eines Partners, die systemübergreifend etwas bedeutet. Verwechseln Sie nicht «Salesforce weiss, welcher Datensatz das ist» mit «Das Unternehmen weiss, welches Geschäftsding das ist». Das sind verschiedene Identitätsprobleme, und das zweite kommt bei Integration und Stammdaten zurück.

Objekte sind mehr als Speicher

Das ist der Wechsel, den Sie vor dem Rest dieses Kapitels vollziehen sollen. Ein Objekt ist nicht nur ein Ort, um Daten zu speichern. Ein Feld ist nicht nur eine Spalte, und eine Beziehung ist nicht nur ein Fremdschlüssel. Ich verwende die Datenbankvergleiche beim Unterrichten, weil sie an Bekanntes anknüpfen. Aber wenn wir dort stehen bleiben, verpassen wir die Architektur.

Das Objekt, das wir wählen, entscheidet, welche Funktionen mitkommen. Der Feldtyp beeinflusst Validierung, Integration, Suche, Berichte und wie andere Systeme die Daten lesen. Die Beziehung entscheidet über Lebenszyklus, Eigentümerschaft, Freigabe und Löschung. Wo wir die Daten ablegen, beeinflusst Speicher, Leistung und Volumen. Und weil all das auf einer gemeinsamen Plattform läuft, kann sich eine Entscheidung, die bei hundert Datensätzen harmlos ist, bei hundert Millionen ganz anders verhalten. Wir nehmen uns diese Entscheidungen eine nach der anderen vor.

Über die Prüfung hinaus: Was KI ändert. Jahrelang haben gute Namen und Beschreibungen den nächsten Leuten in Administration oder Entwicklung geholfen zu verstehen, was wir gebaut haben. Jetzt lesen auch Maschinen diesen Kontext. Ein KI-System, das mit einem Feld namens Flag2__c arbeitet, hat dasselbe Problem wie jemand, der neu im Entwicklungsteam ist: Was bedeutet das? Metadaten sind keine Dekoration mehr; sie sind Teil davon, wie Maschinen die Anwendung verstehen.

Was Architekt:innen hier entscheiden

• Entwerfe ich für die Plattform, auf der ich tatsächlich bin, oder behandle ich Salesforce wie eine generische Datenbank?
• Welche Teile meines Entwurfs sind Geschäftskonzepte und welche Salesforce-Umsetzungsentscheidungen?
• Welches Plattformverhalten kommt mit der Struktur, die ich gleich erstelle?
• Welche Grenzen sind Ausdruck der gemeinsamen Architektur, und welche davon werden diesen Entwurf prägen?
• Wenn diese Struktur später schwer zu ändern sein wird, behandle ich sie als Architekturentscheidung?

In Kapitel 2 haben wir gesagt: Entwerfen Sie nicht aus dem Setup heraus. Jetzt kennen Sie einen weiteren Grund. Ein Klick auf Neues benutzerdefiniertes Objekt gibt Ihnen nicht nur eine Tabelle; er verbindet ein weiteres Stück Ihrer Architektur mit einer metadatengesteuerten, mandantenfähigen Plattform. Aber bevor Sie entscheiden, welches Objekt Sie erstellen, gibt es eine grundlegendere Frage: Sollten diese Daten überhaupt hier liegen? Das kommt als Nächstes.

Weiterlesen

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (auf Englisch), geprüft am 2026-10-02, erneut geprüft am 2026-10-12: Objekt- und Felddefinitionen werden als Metadaten gespeichert, nicht als neue Tabellen; gemeinsame Tabellen (MT_Objects, MT_Fields, MT_Data, MT_Indexes) mit der OrgID als Schlüssel; dieselben Metadaten stellen die REST- und SOAP-APIs bereit.
• Salesforce Architects, Architecture Basics (opens in a new tab) (auf Englisch), geprüft am 2026-10-02, erneut geprüft am 2026-10-12: Governor- und Ausführungslimits, damit Code und Transaktionen gemeinsame Rechenressourcen nicht «monopolisieren».