What Works Today May Fail Tomorrow

🌐 Auch in 19 Sprachen

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

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. (16)

Kapitel 7 von Data Architect und der Beginn von Teil 2: Architektur im großen Maßstab. Zurück: Stammdaten und Identität.

A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. The object is the same, the fields are the same, the relationships are the same. Add a few zeros, and the architecture changes. ⟲

Start with what the platform is built for. Salesforce’s core database handles “upwards of 1.1 trillion transactions per month,” and Salesforce’s own architects describe it as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow (öffnet in einem neuen Tab)). It’s built for transactions, on a multitenant database where Salesforce writes the SQL, not you. At small volumes you can ignore the platform’s shape. At large volumes, it reminds you it’s there. ⟲

So I teach large data volumes with a rough ruler, for records in a single object. At about 1 million, there’s a little drag as dashboards and reports show up. Around 10 million, some effect, but still performing. Heading toward 50 million, you notice it: list views take two, three, four seconds. Past 50 million, you’re driving a convertible with your head out the window, and your hair is blown back: you’ve got to be streamlined, and you’ve got to know what you’re doing. At 100 million or more, I start asking a different question: should these records be here at all? That’s a rule of thumb from the community, not a Salesforce limit. The lesson is that volume changes the design, and most large-data-volume problems are design problems: cheap to prevent, expensive to fix. ⟲

Zum Vergrössern klicken

Teil 1 hat uns das Sehen beigebracht. Teil 2 legt Gewicht auf die Architektur. Dieses Kapitel ist der erste Test: Trägt das Skelett die Nullen?

Image generated with AI. ⟲

Die Ideen in diesem Kapitel

• Planen Sie mit der Anzahl der Nullen, einschließlich Wachstum und der gesamten Aufbewahrungsdauer, nicht mit dem heutigen Volumen. Eine Million Eltern mit je acht Kindern ist kein Problem mit einer Million Datensätzen.
• What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
• Entwerfen Sie sauber, und weichen Sie dann bewusst ab, wenn das Volumen Ihnen einen Grund gibt, und machen Sie das zentrale CRM nicht zu Ihrem Data Warehouse.
• 10,000 children per parent is a design threshold, not a limit: Salesforce draws the same line, and past about 20,000 I’ve seen visible lag. Account pools work, but hide the placeholder parents. ⟲
• Eigentümer mit hohem Volumen bleiben aus der Rollenhierarchie heraus, oder in einer eigenen, stabilen Rolle ganz oben, und aus den Gruppen der Freigaberegeln heraus.
• Wem maschinell erstellte Datensätze gehören, hängt davon ab, ob Eigentümerschaft für die Freigabe zählt.
• Im großen Maßstab ist eine Neuausrichtung der Sicherheit eine Datenoperation: Freigabeberechnungen zurückstellen, in einer Full Sandbox proben, einmal neu berechnen. Und machen Sie Daten niemals öffentlich, weil privat langsamer ist.
• Wenn Sie heute nicht archivieren, werden Sie es je tun? Entscheiden Sie über das Löschen am ersten Tag, sichern Sie vor dem Löschen, und halten Sie Archive auffindbar.
• Ob archivierte Daten für Agenten erreichbar bleiben, entscheidet das Geschäft.

Where volume causes problems

Was wächst	Was es verlangsamt	Wo es behandelt wird
Datensätze in einem Objekt	Abfragen, Listenansichten, Berichte	Modul 1; Kapitel 8
Kinder unter einem Elterndatensatz, Datensätze unter einem Eigentümer	Sperren, Neuberechnung der Freigabe	Modul 2
Children under one master-detail parent	Locking, roll-ups, cascade delete, a hard-to-undo choice	Module 2
Benutzer, Rollen, Gruppen und Regeln	Neuberechnung des Zugriffs, Neuausrichtungen	Modul 3
Historie, die niemand nutzt	Alles, dazu Speicher und Risiko	Modul 4

Der Weg durch dieses Kapitel

Vier Module, jedes steht für sich.

1. When Volume Changes Everything. Built for transactions, the ruler, the Number of Zeros at 30% growth, denormalizing for scale, and keeping analytics out of core. ⟲
2. Hot Spots: Ownership, Parent and Lookup Skew. Too many records pointing at one thing, account pools, master-detail at volume (count the children before you choose the relationship), high-volume owners, and who owns agent-created records. ⟲
3. Wenn Volumen auf das Freigabemodell trifft. Eigentümerschaft als Zugriffshebel, stabile Hierarchien, zurückgestellte Freigabeberechnungen, granulares Sperren und Partnertrennung im großen Maßstab.
4. Wenn Sie heute nicht archivieren …. Lebenszyklus ab dem ersten Tag, Sicherung vor dem Löschen, wo das Archiv liegt, die Archivierung in drei Schritten und Agenten gegenüber alten Daten.

Was Architekt:innen hier entscheiden

• Wie weit jedes Objekt wächst, mit Wachstum und über seine Aufbewahrungsdauer.
• Wo sich Datensätze ballen, und welche Ballungen gefährlich sind.
• Was Eigentümerschaft bedeutet für jedes Objekt mit hohem Volumen, auch für die, die Agenten erstellen.
• Wie das Zugriffsmodell skaliert, und wie große Neuausrichtungen geplant werden.
• Wie Daten hinausgehen: Archivierung, Bereinigung, Sicherung, und wer sie noch finden kann.

Über die Prüfung hinaus: Agenten fügen Nullen hinzu. Sie können zehn Datensätze erstellen, wo ein Mensch einen erstellt hat, standardmäßig alle besitzen, Daten schneller abrufen als irgendjemand und an Archive gelangen, sofern niemand entscheidet, dass sie das nicht sollen. Jedes Modul endet damit, was KI an seinem Teil des Problems ändert.

Weiterlesen

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (öffnet in einem neuen Tab) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (öffnet in einem neuen Tab) (Winter ‘27), checked 2026-11-01. ⟲

Weiter: Architektur für Abfragen und Abruf