Skip to content
SteveTechArcSteveTechArc Courses

What Works Today May Fail Tomorrow

另有 19 種語言版本

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) · Deutsch (Schweiz)

Data Architect 第 7 章，也是第 2 部分：大規模架構的開始。上一章：主資料與身分。

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 （在新標籤頁中開啟）). 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. ⟲

The LDV ruler The LDV ruler, four steps in records in a single object. One million: a little drag; dashboards and reports take a moment, depending on how you filter. Ten million: some effect, but still performing. Fifty million: the convertible; list views take two, three, four seconds, reports and dashboards take time, and past it your hair is blown back. One hundred million and up: should it be here? When will you archive, and is this operational data or an audit log? Underneath: records in a single object; a rule of thumb from the community, not a Salesforce limit. {"author": "Steve Simpson", "blueprint": "1.1.0", "builder": "standard 1.53.0", "built": "2026-10-29", "id": "DGM-DA-LDV-11", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} 1 million a little drag YOU NOTICE Dashboards and reports take a moment Depends on how you filter 10 million some effect YOU NOTICE Some effect Still performing 50 million the convertible YOU NOTICE List views take 2, 3, 4 seconds Reports and dashboards take time Past it, your hair is blown back 100 million + should it be here? YOU ASK When will you archive? Operational data, or an audit log? Records in a single object. A rule of thumb from the community, not a Salesforce limit. © 2026 Twinshark LLC · stevetecharc.com
點擊放大

第 1 部分教會我們去看。第 2 部分給架構加上重量。這一章是第一次考驗：骨架撐得住這些零嗎？

A small four-seat propeller plane parked beside a wide-body passenger jet that towers over it: the same job, built for a hundred times the load.

Image generated with AI. ⟲

本章的思想

Section titled “本章的思想 ”
  • **用「零的個數」來規劃，**包括增長和整個保留期，而不是今天的資料量。100 萬個父記錄、每個帶 8 個子記錄，不是一個 100 萬條記錄的問題。
  • What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
  • 先乾淨地設計，再在資料量給你理由時有意識地退一步，並且不要把核心 CRM 變成你的資料倉儲。
  • 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. ⟲
  • **擁有大量記錄的所有人要放在角色階層之外，**或者放在頂部一個穩定的獨立角色裡，並且不進入共用規則的組。
  • 機器建立的記錄歸誰所有，取決於所有權對共用是否重要。
  • **在大規模下，安全調整就是一次資料操作：**推遲共用計算，在完整沙箱裡演練，只重新計算一次。並且永遠不要因為私有更慢就把資料設為公開。
  • **如果你今天不歸檔，你還會歸檔嗎？**從第一天就決定刪除，刪除之前先備份，並讓歸檔可以被找到。
  • 歸檔資料是否仍然能被代理程式存取，由業務決定。

Where volume causes problems

Section titled “Where volume causes problems”
什麼在增長它拖慢什麼在哪裡講
一個物件裡的記錄查詢、清單檢視、報表模組 1；第 8 章
一個父記錄下的子記錄、一個所有人名下的記錄鎖、共用重新計算模組 2
Children under one master-detail parentLocking, roll-ups, cascade delete, a hard-to-undo choiceModule 2
使用者、角色、組和規則存取權限重新計算、調整模組 3
沒人用的歷史一切，外加儲存和風險模組 4

本章的路線

Section titled “本章的路線 ”

四個模組，每個都可以單獨閱讀。

  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. **當資料量遇上共用模型。**所有權作為存取槓桿、穩定的層級、推遲的共用計算、細粒度鎖定，以及大規模的合作夥伴隔離。
  4. **如果你今天不歸檔……。**從第一天開始的生命週期、刪除前備份、歸檔放在哪裡、三步歸檔，以及代理程式與舊資料。

架構師在這裡決定什麼

Section titled “架構師在這裡決定什麼 ”
  • **每個物件會長到多大，**包括增長和整個保留期。
  • **記錄在哪裡扎堆，**以及哪些扎堆是危險的。
  • **所有權意味著什麼，**對每一個大數據量物件，包括代理程式建立的物件。
  • **存取模型如何擴充套件，**以及大型調整如何規劃。
  • **資料如何離開：**歸檔、清除、備份，以及誰還能找到它。

**考試之外：**代理程式會增加零。一個人建立一條記錄的地方，它們可能建立十條，預設擁有所有這些記錄，比任何人都更快地檢索資料，並且能觸及歸檔，除非有人決定它們不應該這樣。每個模組的結尾都會講 AI 對它那一部分問題帶來了什麼改變。

延伸探索

Section titled “延伸探索 ”

下一章：查詢與檢索架構

關注我

© 2023–2026 Twinshark LLC. All rights reserved. · 內容使用

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

法律宣告以英文書寫，以英文版本為準。