What Works Today May Fail Tomorrow
Dostępne także w 19 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Rozdział 7 kursu Data Architect i początek części 2: Architektura w skali. Wstecz: Dane podstawowe i tożsamość.
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 (otwiera się w nowej karcie)). 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. ⟲
Część 1 nauczyła nas patrzeć. Część 2 dokłada architekturze ciężaru. Ten rozdział to pierwszy sprawdzian: czy szkielet uniesie te zera?
Image generated with AI. ⟲
Idee w tym rozdziale
Dział zatytułowany „Idee w tym rozdziale ”- Planuj według Liczby Zer, łącznie ze wzrostem i całym okresem retencji, a nie według dzisiejszego wolumenu. Milion rekordów nadrzędnych z ośmioma podrzędnymi każdy to nie jest problem miliona rekordów.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
- Projektuj czysto, a potem świadomie się wycofuj, gdy wolumen da ci powód, i nie zamieniaj podstawowego CRM w swoją hurtownię danych.
- 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. ⟲
- Trzymaj właścicieli dużej liczby rekordów poza hierarchią ról albo w osobnej, stabilnej roli na samej górze, i poza grupami reguł udostępniania.
- Kto powinien być właścicielem rekordów utworzonych przez maszyny, zależy od tego, czy własność ma znaczenie dla udostępniania.
- W dużej skali przebudowa zabezpieczeń to operacja na danych: odrocz obliczenia udostępniania, przećwicz w pełnej kopii sandboxa, przelicz tylko raz. I nigdy nie upubliczniaj danych dlatego, że prywatne są wolniejsze.
- Jeśli nie archiwizujesz dziś, to czy kiedykolwiek będziesz? Decyduj o usuwaniu od pierwszego dnia, rób kopię zapasową przed usunięciem i zadbaj, żeby archiwum dało się znaleźć.
- To, czy dane zarchiwizowane pozostaną dostępne dla agentów, jest decyzją biznesu.
Where volume causes problems
Dział zatytułowany „Where volume causes problems”| Co rośnie | Co spowalnia | Gdzie o tym mowa |
|---|---|---|
| Rekordy w jednym obiekcie | Zapytania, widoki list, raporty | Moduł 1; rozdział 8 |
| Rekordy podrzędne jednego rekordu nadrzędnego, rekordy jednego właściciela | Blokady, przeliczanie udostępniania | Moduł 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Użytkownicy, role, grupy i reguły | Przeliczanie dostępu, przebudowy | Moduł 3 |
| Historia, z której nikt nie korzysta | Wszystko, a do tego miejsce i ryzyko | Moduł 4 |
Droga przez ten rozdział
Dział zatytułowany „Droga przez ten rozdział ”Cztery moduły, każdy samodzielny.
- 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. ⟲
- 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. ⟲
- Gdy wolumen spotyka model udostępniania. Własność jako dźwignia dostępu, stabilne hierarchie, odroczone obliczenia udostępniania, blokowanie granularne i izolacja partnerów w dużej skali.
- Jeśli nie archiwizujesz dziś…. Cykl życia od pierwszego dnia, kopia zapasowa przed usunięciem, gdzie trzymać archiwum, archiwum w trzech krokach oraz agenci i stare dane.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Jak duży urośnie każdy obiekt, łącznie ze wzrostem i całym okresem retencji.
- Gdzie rekordy się skupiają i które skupiska są niebezpieczne.
- Co oznacza własność dla każdego obiektu o dużym wolumenie, także tych tworzonych przez agentów.
- Jak skaluje się model dostępu i jak planuje się duże przebudowy.
- Jak dane opuszczają system: archiwizacja, czyszczenie, kopie zapasowe i kto nadal może je znaleźć.
Poza egzaminem: agenci dokładają zer. Mogą utworzyć dziesięć rekordów tam, gdzie człowiek tworzy jeden, domyślnie być właścicielami ich wszystkich, pobierać dane szybciej niż ktokolwiek i sięgać do archiwów, chyba że ktoś zdecyduje inaczej. Każdy moduł kończy się tym, co AI zmienia w jego części problemu.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (otwiera się w nowej karcie), checked 2026-11-01. ⟲
- Salesforce Developers, Designing Record Access for Enterprise Scale (otwiera się w nowej karcie) (Winter ‘27), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (otwiera się w nowej karcie) (Winter ‘27), checked 2026-11-01. ⟲