What Works Today May Fail Tomorrow
Disponibile anche in 19 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Capitolo 7 di Data Architect e inizio della Parte 2: Architettare su larga scala. Precedente: Dati master e identità.
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 (si apre in una nuova scheda)). 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. ⟲
La Parte 1 ci ha insegnato a vedere. La Parte 2 mette peso sull’architettura. Questo capitolo è la prima prova: lo scheletro regge gli zeri?
Image generated with AI. ⟲
Le idee di questo capitolo
Sezione intitolata “Le idee di questo capitolo ”- Pianifica con il Numero di Zeri, includendo la crescita e tutto il periodo di conservazione, non il volume di oggi. Un milione di padri con otto figli ciascuno non è un problema da un milione di record.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
- Progetta in modo pulito, poi fai un passo indietro di proposito quando il volume te ne dà un motivo, e non trasformare il CRM principale nel tuo 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. ⟲
- I titolari ad alto volume restano fuori dalla gerarchia dei ruoli, o in un ruolo proprio e stabile in cima, e fuori dai gruppi delle regole di condivisione.
- Chi è titolare dei record creati dalle macchine dipende da quanto la titolarità conta per la condivisione.
- Su larga scala, un riallineamento della sicurezza è un’operazione sui dati: rimanda i calcoli di condivisione, prova in una sandbox Full, ricalcola una volta. E non rendere mai pubblici i dati perché il privato è più lento.
- Se non archivi oggi, archivierai mai? Decidi l’eliminazione dal primo giorno, fai il backup prima di eliminare e mantieni gli archivi reperibili.
- Se i dati archiviati restano raggiungibili dagli agenti lo decide il business.
Where volume causes problems
Sezione intitolata “Where volume causes problems”| Cosa cresce | Cosa rallenta | Dove se ne parla |
|---|---|---|
| I record di un oggetto | Query, viste elenco, report | Modulo 1; capitolo 8 |
| I figli sotto un padre, i record sotto un titolare | Blocchi, ricalcolo della condivisione | Modulo 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Utenti, ruoli, gruppi e regole | Ricalcolo degli accessi, riallineamenti | Modulo 3 |
| Storico che nessuno usa | Tutto, più spazio di archiviazione e rischio | Modulo 4 |
Il percorso di questo capitolo
Sezione intitolata “Il percorso di questo capitolo ”Quattro moduli, ognuno si regge da solo.
- 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. ⟲
- Quando il volume incontra il modello di condivisione. La titolarità come leva di accesso, gerarchie stabili, calcoli di condivisione rimandati, blocco granulare e isolamento dei partner su larga scala.
- Se non archivi oggi…. Il ciclo di vita dal primo giorno, il backup prima dell’eliminazione, dove vive l’archivio, l’archiviazione in tre passaggi e gli agenti davanti ai dati vecchi.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- Quanto cresce ogni oggetto, con la crescita e per tutto il periodo di conservazione.
- Dove si concentrano i record, e quali concentrazioni sono pericolose.
- Cosa significa la titolarità per ogni oggetto ad alto volume, compresi quelli che creano gli agenti.
- Come scala il modello di accesso, e come si pianificano i grandi riallineamenti.
- Come escono i dati: archiviazione, eliminazione definitiva, backup, e chi può ancora trovarli.
Oltre l’esame: gli agenti aggiungono zeri. Possono creare dieci record dove una persona ne creava uno, esserne titolari per impostazione predefinita, recuperare dati più in fretta di chiunque e arrivare agli archivi, a meno che qualcuno decida che non devono. Ogni modulo si chiude con cosa cambia l’IA nella sua parte del problema.
Per approfondire
Sezione intitolata “Per approfondire ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce Developers, Designing Record Access for Enterprise Scale (si apre in una nuova scheda) (Winter ‘27), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (si apre in una nuova scheda) (Winter ‘27), checked 2026-11-01. ⟲
Successivo: Architettura delle query e del recupero dei dati