Eigentümerschafts-, Eltern- und Nachschlage-Schieflage

🌐 Auch in 19 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen Dieser Abschnitt hat sich im Englischen geändert und wurde noch nicht neu übersetzt. (35)

Modul 2 von 4 im Kapitel Für Skalierung entwerfen, Kapitel 7 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Wenn Volumen alles verändert · Weiter: Wenn Volumen auf das Freigabemodell trifft

Die Frage, die dieses Modul beantwortet: Was passiert, wenn zu viele Datensätze auf eine Sache zeigen?

Probleme mit großen Datenvolumen haben nicht immer damit zu tun, dass es zu viele Datensätze gibt. Manchmal geht es darum, dass zu viele Datensätze mit derselben Sache verbunden sind: einem Eigentümer, einem Account, einem Elterndatensatz, einem Nachschlagewert. Denken Sie an den Verkehr. Eine Stadt kann Millionen Autos haben und trotzdem funktionieren. Der Ärger beginnt, wenn alle um 17 Uhr dieselbe Autobahnausfahrt nehmen. Die Summe zählt, und die Ballung auch. Ich nenne diese Ballungen Hotspots; Salesforce nennt sie Datenschieflage (Data Skew). Es gibt mehrere Arten, und eine Idee darunter: zu viel Aktivität, die auf einen Punkt im Modell zuläuft.

Eltern-Kind-Schieflage

The easiest to picture. One account with 100 contacts: nothing unusual. A thousand: probably fine. Ten thousand: now I’m paying attention. My design rule is no more than about 10,000 children under one parent, and Salesforce’s guidance draws the same line: “a large number of child records (10,000 or more) with a single parent account” is a common cause of poor performance (Parent-Child Data Skew (öffnet in einem neuen Tab)). Salesforce’s own example shows why. Put 300,000 contacts under one account. A user who can see one of those contacts gets implicit access to the account. When that user loses access to the contact, Salesforce has to check the other 299,999 contacts before it can decide whether to remove the user’s access to the account. Do that for many users at once, and it gets expensive. Salesforce also names one way to take part of that cost away: where your security requirements allow, set the child object to Controlled by Parent, so there are no parent implicit shares to maintain (same source). In practice, it’s the most common skew I see, and I’ve seen users notice visible lag at around 20,000 children under one parent. Where somebody feels it depends on what the system is doing. That’s why 10,000 is a design threshold, not a promise that record 10,001 breaks anything. The real question is: why are all these records pointing at the same parent? ⟲

Zum Vergrößern klicken

Step 1 of 2: every line points at one account. That’s the hot spot. ⟲

Der Account „Nicht zugeordnet“ und Account-Pools

The classic case is contacts with no real account. Somebody decides every contact needs an account, so they create Unassigned Contacts and put every contact without an account there. Problem solved, until there are 300,000 contacts under it. We created an artificial hot spot because the model required us to put everything somewhere, and the relationship doesn’t even carry business meaning. It worked beautifully at 500 records. Then the Number of Zeros caught up with it. ⟲

What do you do when you’ve got a million contacts under it? I’ve seen child accounts by state, one unhandled-contacts account per state. I’ve seen an automatic version: whenever an account reaches 10,000, create another one. It can be a little awkward, but it spreads the load. ⟲

One answer is an account pool: Unassigned Contacts 001, 002, 003 and so on, with the children spread across them, each kept under the threshold. It works, and it’s Salesforce’s own advice: “Distribute child records so that no parent has more than 10,000 child records,” and for contacts without real accounts, “set up several dummy accounts and distribute the contacts among them” (Best Practices for Deployments with Large Data Volumes: General (öffnet in einem neuen Tab), Winter ‘27). But those aren’t real accounts; they’re architecture artifacts. Users will ask who “Unassigned Contacts 017” is and why it’s in their search results. So when I use a pool, I hide the placeholder parents from normal business experiences as much as I can. It’s a recurring trade-off: sometimes scale forces a structure that exists for the platform, not the business. When it does, don’t pretend it’s business data. Name it, document it, hide it where appropriate. ⟲

Zum Vergrößern klicken

Step 2 of 2: the same contacts, spread across a pool. Nothing moved but where they point. ⟲

Master-Detail at Volume

Contacts under an account are a lookup. Master-detail is a different decision, and it’s one you make in the data model, long before the records arrive. Here’s the question I ask in class: would an invoice ever have more than 10,000 line items? No, it never would. So an invoice and its lines can be master-detail all day long. Now ask the same question of every master-detail relationship you’re about to build: at the volume we expect, will one parent ever pass 10,000 children? ⟲

Salesforce draws the same line: “As a best practice, don’t exceed 10,000 child records for a master-detail relationship” (Überlegungen zu Objektbeziehungen (öffnet in einem neuen Tab)). Master-detail is the strongest relationship Salesforce gives you, and that’s exactly why the number matters. The detail record has no owner of its own; its access is controlled by the parent. Delete the parent, and every child goes with it. A child can’t move to another parent unless you allowed reparenting. Roll-up summaries on the parent have to keep up as the children change. And saving a child can lock the parent, which is why Salesforce’s loading advice is to group child records by their parent “to minimize locking conflicts” (Loading Data from the API (öffnet in einem neuen Tab)). With ten children, none of that is noticeable. With a hundred thousand, every one of them is. ⟲

It’s also hard to undo. A master-detail relationship can only be converted to a lookup when the parent has no roll-up summary fields, and converting it changes the child’s sharing to Public Read/Write (same source). By the time volume tells you it was the wrong choice, the relationship may be holding up reports, sharing and automation. Count the children before you choose the relationship. ⟲

Steve Trucking has one of these decisions in its model. Each Retail Partner sends a Manifest (Manifest__c, a custom object) for each distribution center, for each working day. Manifest is custom, so master-detail to the partner’s account is allowed, and it’s tempting: the manifest would inherit the partner’s sharing, which is exactly the isolation we want. Now count. Our largest partner has nine or more DCs: nine manifests a working day, about 2,700 a year. Past 10,000 in under four years, under one parent, and every manifest revised on the day, so every revision would touch the partner’s account. That’s why the model makes Manifest a lookup and handles partner access through sharing. The invoice stays small; the manifests keep coming. ⟲

Zum Vergrößern klicken

Step 1 of 2: master-detail, where the parent stays small. ⟲

Zum Vergrößern klicken

Step 2 of 2: a lookup, where the children keep coming. ⟲

Watch Account with its contacts and opportunities too. It isn’t master-detail, but it behaves like a pseudo master-detail, with implicit sharing to the parent, which is why the 10,000 guidance shows up there as well. None of this means never use master-detail at scale. It means don’t choose a strongly coupled relationship and then act surprised that the records are strongly coupled. ⟲

Test knowledge. Know the 10,000-children guidance for master-detail, and what master-detail brings with it at volume: no owner on the detail (access controlled by the parent), cascade delete, no reparenting unless allowed, roll-up summaries, and parent locking when children are saved. Converting to a lookup needs no roll-up summaries on the master. ⟲

Eigentümerschafts-Schieflage

Now the owner. I ask the room: who owns a million records? The admin? Is the admin sitting there creating a million records? Usually it’s the integration user or the data load user. The records come in, and nobody knows who to give them to. We create an integration user, it creates records, nobody thinks about ownership (“it’s just the integration user”), and a year later that user owns 2 million records. Salesforce calls it ownership data skew when one user owns more than 10,000 records of an object, and the classic example is all the unassigned leads parked on a dummy user (Ownership Data Skew (öffnet in einem neuen Tab)). That doesn’t mean a user can never own more. It means understanding the consequences: ownership isn’t a Created By stamp. It drives the role hierarchy, sharing rules and recalculation: behind the scenes, Salesforce keeps share records for the owner’s records above them in the role hierarchy. Attach millions of records to one owner who sits deep in the sharing model, and changing anything about that owner gets expensive. ⟲

The guidance matches what I teach in class. If a few users must own a very large number of records, give them no role; if they need one, put them in a separate role at the top of the hierarchy and don’t move them, and keep them out of public groups used as sources for sharing rules (same source). One catch with the top role: that user inherits access to all the data owned by or shared with the users below them. You could spread the records across a bunch of users instead, but for an integration user or a data load user, that typically isn’t worth the trouble. ⟲

We’re isolating the hot spot from the structures that trigger recalculation. Imagine a user who owns 5 million records being moved in a reorganization. That isn’t moving a box on the org chart; Salesforce may have to re-evaluate access across 5 million records. At this scale, organizational changes become data operations. ⟲

Test knowledge. Know the skew thresholds and the fixes: ownership skew when one user owns more than 10,000 records of an object (no role, or a separate role at the top that doesn’t move, and out of public groups used by sharing rules); parent-child skew at about 10,000 children under one parent. ⟲

Wem sollen maschinell erstellte Datensätze gehören?

Wer einen Datensatz erstellt hat und wem er gehört, ist nicht dieselbe Frage. Redrock sendet 500.000 Lieferungen über die API, und der Integrationsbenutzer erstellt sie. Sollen sie ihm für immer gehören? Vielleicht, aber nicht nur, weil er sie erstellt hat. Und jetzt erstellen auch Agenten Datensätze.

Meine Position: Es hängt davon ab, ob Eigentümerschaft für die Freigabe zählt. Der Integrations- oder Agentenbenutzer ist ein gültiger Benutzer und darf Datensätze besitzen. Wenn Eigentümerschaft in diesem Objekt den Zugriff steuert (über die Rollenhierarchie oder Freigaberegeln), weisen Sie die Datensätze dem Eigentümer zu, den das Geschäft verlangt: einem echten Benutzer, einer Warteschlange, wo das Objekt eine unterstützt, oder einem eigens dafür angelegten Eigentümer-Benutzer. Wenn Eigentümerschaft den Zugriff nicht steuert, kann es die bessere Wahl sein, den Agenten- oder Integrationsbenutzer als Eigentümer zu belassen, weil der Prüfpfad direkt zu dem zurückführt, was den Datensatz erstellt hat. So oder so: Entscheiden Sie, was Eigentümer für dieses Objekt bedeutet, statt jeden maschinell erstellten Datensatz mechanisch neu zuzuweisen, weil Datensätze normalerweise Menschen gehören. Und denken Sie daran, dass „Erstellt von“ weiterhin da ist: Eine Neuzuweisung der Eigentümerschaft löscht nicht die Tatsache, dass die Integration ihn erstellt hat. „Erstellt von“ und Eigentümer beantworten unterschiedliche Fragen. Ein Feld beide beantworten zu lassen, so entsteht ein schlechtes Modell.

Nachschlage-Schieflage

A lookup can be a hot spot too: millions of records pointing at the same location, category, reference record or configuration record. Salesforce’s own training defines it: “Lookup skew happens when a very large number of records are associated with a single record in the lookup object” (Large Data Volumes: Design Your Data Model (öffnet in einem neuen Tab)). The danger isn’t “lots of lookups.” It’s concentration combined with activity: if millions of active records reference one record, and transactions keep touching that relationship, operations start colliding over it. That’s record locking, which chapter 11 covers. For now, recognize the shape: many active records, one heavily referenced record, worth inspecting. ⟲

Nicht jede Schieflage ist gleich gefährlich

Lernen Sie nicht „10.000 = schlecht“ auswendig. Fünfzigtausend historische Datensätze, die auf einen Referenzwert zeigen, der sich nie ändert, ohne Rolle in der Freigabe und fast ohne gleichzeitige Aktivität, können völlig in Ordnung sein. Zwanzigtausend aktive Datensätze unter einem Elterndatensatz, der sich oft ändert, die Freigabe steuert, Rollups speist und von mehreren Integrationen zugleich getroffen wird, sind eine ganz andere Geschichte. Volumen hat eine Form, und Schieflage auch. Wie viele Datensätze laufen dort zusammen? Wie oft ändern sie sich? Ändert sich der Elterndatensatz? Steuert die Beziehung Freigabe oder Sperren? Aktualisieren Integrationen die Kinder gleichzeitig? Löst das Verschieben des Eigentümers oder Elterndatensatzes eine Neuberechnung aus? Die Zahl sagt mir, wo ich hinschauen muss; das Verhalten sagt mir, wie besorgt ich sein muss.

Steve Trucking: Wo sind die Hotspots?

Für fünf Jahre haben wir rund 9 Millionen Arbeitsaufträge hochgerechnet. Angenommen, jemand sagt: „Lassen wir jede Lieferung dem Integrationsbenutzer gehören.“ Neun Millionen Datensätze, ein Eigentümer. Zählt Eigentümerschaft für die Freigabe von Lieferungen? Wenn nicht, kann ein eigener Eigentümer mit hohem Volumen funktionieren, isoliert von Rollenhierarchie und Freigaberegel-Gruppen wie oben. Wenn doch, ist ein einzelner Integrations-Eigentümer das falsche Geschäftsmodell: Die Integration erstellt den Datensatz; das heißt nicht, dass er ihr gehören sollte.

Then the Retail Partner. Every work order carries its partner, deliberately, because partner isolation matters. But if one partner is 40% of the business, five years of deliveries is about 3.6 million work orders under one partner account. Does that make the relationship wrong? No. The business relationship is real, and I’m not going to invent 400 fake Redrock accounts because I don’t like the count. But I am going to look for a split the business would recognize. Each partner has real distribution centers, so a child account per DC under the partner spreads the work orders nine or more ways while every account still means something. Add archiving completed deliveries after the claims window, and the active children per parent stay low. ⟲

Das ist der Unterschied zwischen den beiden Lösungen. „Nicht zugeordnete Kontakte“ war schon künstlich, also verliert ein Aufteilen in einen Pool keine Bedeutung. Redrock ist ein echter Partner; ihn in Redrock 001, 002 und 003 aufzuteilen, würde das Modell verfälschen. Ihn in seine echten Verteilzentren aufzuteilen, nicht. Lösungen für den Maßstab müssen trotzdem die Bedeutung bewahren. Manchmal ist die Antwort eine andere Beziehung, eine andere Freigabestrategie, ein anderes Abfragemuster, ein anderes Speichermodell oder eine andere Archivierungsrichtlinie, niemals eine falsche Identität für eine echte geschäftliche Entität.

Zum Vergrößern klicken

Inspect, not bad. Concentration matters, not the total. ⟲

Finden Sie die Hotspots im Diagramm

Hier ist eine Übung, die ich mag. Nehmen Sie das Datenmodell und schauen Sie auf die Pfeile, nicht nur auf die Objekte. Fragen Sie bei jeder Beziehung: Wie viele Datensätze können sich auf dieser Seite des Pfeils stapeln? Stellen Sie dann dieselbe Frage zum Eigentümer. Stellen Sie sich jetzt drei Jahre vor, fünf, zehn. Wo ballen sich die Datensätze? Dort versteckt sich oft das Problem von morgen.

Über die Prüfung hinaus: Was KI ändert. Ein Mensch erstellt vielleicht 20 Datensätze am Tag; ein Agent könnte Tausende erstellen. Geben Sie einem Agenten einen eigenen Benutzer, lassen Sie ihm jeden Datensatz gehören, und Eigentümerschafts-Schieflage entsteht weit schneller, als sie es bei Menschen je tat. Eigentümerschaft durch Agenten ist nicht falsch, aber entscheiden Sie, was Eigentümer für von Agenten erstellte Datensätze bedeutet, bevor das Volumen den Standard zum Teil der Architektur macht.

Was Architekt:innen hier entscheiden

• Wo Eltern-Kind-, Eigentümerschafts- oder Nachschlagebeziehungen Datensätze ballen und ob sie aktiv genug sind, um zu Hotspots zu werden.
• Ob maschinell erstellte Datensätze dem Integrations- oder Agentenbenutzer gehören bleiben oder neu zugewiesen werden, weil Eigentümerschaft den Zugriff steuert.
• Wie Eigentümer mit hohem Volumen von der Rollenhierarchie und den Freigaberegel-Gruppen isoliert werden.
• Wann ein künstlicher Elterndatensatz in einen Pool aufgeteilt werden kann und wann eine echte Beziehung stattdessen eine sinnvolle Aufteilung braucht.
• Whether each master-detail relationship stays under about 10,000 children per parent at projected volume, or should be a lookup. ⟲

Eine Million Datensätze, verteilt auf Tausende Eigentümer und Elterndatensätze, verhält sich ganz anders als eine Million Datensätze, die auf eine Stelle zeigen. Suchen Sie die Hotspots früh: Eigentümer, Elterndatensätze, Nachschlagebeziehungen, überall dort, wo die Anzahl der Nullen zusammenläuft. Das Ziel ist nicht, jede große Beziehung zu beseitigen; manche bilden das Geschäft richtig ab. Es geht darum zu wissen, wohin der Verkehr fließt, bevor Sie die Autobahn eröffnen, denn wenn erst Millionen Datensätze auf dieselbe Ausfahrt zusteuern, wird es viel schwerer, die Straße zu ändern.

Weiterlesen

• Salesforce Developers, Best Practices for Deployments with Large Data Volumes, Loading Data from the API (öffnet in einem neuen Tab) (Winter ‘27): group child records by parent to minimize locking conflicts, checked 2026-11-01. ⟲
• Salesforce Help, Überlegungen zu Objektbeziehungen (öffnet in einem neuen Tab): no more than 10,000 child records for a master-detail relationship; converting master-detail to lookup, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (öffnet in einem neuen Tab) and Parent-Child Data Skew (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes: General (öffnet in einem neuen Tab) (Winter ‘27), the 10,000-record owner and parent guidance, checked 2026-11-01. ⟲
• Trailhead, Large Data Volumes: Design Your Data Model (öffnet in einem neuen Tab): parent-child, ownership and lookup skew, checked 2026-11-01. ⟲
• Salesforce engineering blog, Managing Lookup Skew to Avoid Record Lock Exceptions (öffnet in einem neuen Tab) (2013; older, but still the clearest explanation; checked 2026-11-01). ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲