為規模而設計
另有 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 章的學習指南。請先閱讀四個模組；這一頁幫你檢查自己記住了什麼。
**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。
這一章開啟第 2 部分，以及考試的「大數據量」部分（20%），外加「資料建模」部分的資料傾斜。查詢設計在下一章；這一章講的是資料量、熱點、大規模共用和生命週期。平台的數字會變，依賴它們之前請先檢視當前的數字。
邊學邊打勾。每一條都連結到講授它的地方。
LDV-1：一個能擴充套件的模型
- 我知道要按整個保留期內的增長來給設計定規模，而不是按今天的資料量，並且會把子記錄乘進去。（別問它今天有多大、現在把子記錄乘進去）
- 我知道資料量影響的不只是查詢：還有共用、所有權、鎖定、清單檢視、報表、批次處理、載入、刪除和恢復。（變慢的不只是查詢）
- 我知道什麼時候規模足以支援受控的反規範化，以及它的代價。（乾淨的模型可能變成昂貴的模型）
- 我知道不要把運營 CRM 變成資料倉儲，也知道報表快照不是資料倉儲策略。（不要把核心 CRM 變成你的資料倉儲）
- 我知道資料量是有形狀的：做什麼的兩千萬條記錄？（資料量是有形狀的）
DM-5：資料傾斜
- Test knowledge: I know parent-child skew and the guidance of no more than about 10,000 children per parent; it’s a design threshold, not a cliff. Where security allows, Controlled by Parent on the child takes away the parent’s implicit shares to maintain. (Parent-Child Skew) ⟲
- 我知道用客戶池修復人為的父記錄，並把佔位父記錄對使用者藏起來。（「未分配」客戶與客戶池）
- Test knowledge: I know Salesforce’s best practice of no more than 10,000 children for one master-detail parent, and what master-detail brings at volume: no owner on the detail, cascade delete, no reparenting unless allowed, roll-up summaries, parent locking. I count the children before I choose master-detail or lookup, and I know converting back to a lookup needs no roll-up summaries on the master. (Master-Detail at Volume) ⟲
- Test knowledge: I know ownership skew (one user owning more than 10,000 records of an object) and the fix: no role, or a separate stable role at the top, and out of public groups used by sharing rules. (Ownership Skew) ⟲
- 我知道查閱傾斜：很多活動記錄指向同一條記錄，以及它可能引起的記錄鎖定。（查閱傾斜）
- 我能根據活動，而不只是數量，區分危險的傾斜和無害的傾斜。（並非每種傾斜都同樣危險）
- 對一個真實業務實體上的傾斜，我用有含義的拆分來修復（每個配送中心一個子客戶），絕不製造它的假副本。（Steve Trucking：熱點在哪裡？）
DM-2：大規模共用
- 我知道存取結構（所有人、角色、組、共用）也是資料，而且會隨規模增長。（共用也是資料）
- Test knowledge: I know the share object (
AccountShare,Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. (The Share Table Has Its Own Number of Zeros) ⟲ - 我知道在大數據量下改動角色階層是一次資料操作，所以穩定性是一項設計特性。（角色階層不是組織架構圖）
- Test knowledge: I know deferred sharing calculations: make all the changes, then recalculate once in a maintenance window, tested first in a full copy sandbox. (Sharing Recalculation Is Real Work) ⟲
- Test knowledge: I know granular locking (on by default) lets unrelated group operations run together, but doesn’t fix a poor design. (Granular Locking Helps) ⟲
- 我知道效能不是把應該私有的資料設為公開的藉口。（不要為了最佳化而丟掉安全）
LDV-2：歸檔與清除
- 我能把保留、歸檔和清除分開，並在專案開始時就定下來。（刪除不可避免）
- 我知道在刪除任何東西之前先把備份做好，也知道備份和歸檔是不同的能力（Salesforce Backup & Recover、Archive）。（刪除之前先備份）
- Test knowledge: I can choose an archive destination by constraint: big objects, an external store through Salesforce Connect (OData, SQL adapters or a custom adapter), or Salesforce’s Archive. (Where Should the Archive Live?) ⟲
- Test knowledge: I know what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. (Where Should the Archive Live?) ⟲
- Test knowledge: I know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, Bulk API 2.0 hard delete; children before parents. (Deletion Is Inevitable) ⟲
- 我知道三步歸檔（複製並標記、驗證、刪除並切換），也知道它必須可以重啟。（三步歸檔）
- 我知道歸檔資料必須保持可查閱，並保留它的安全性。（沒人找得到的歸檔，幾乎就是刪除、歸檔仍然必須安全）
考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。
- Salesforce is built for transactions on structured data, on a multitenant database where Salesforce writes the SQL. Millions of records perform well because somebody designed for them. (Built for Transactions) ⟲
- My large data volume ruler (records in one object): around a million, a little drag; ten million, some effect but still performing; heading toward fifty million, list views take seconds, and past it you’re the convertible with your hair blown back; at a hundred million or more, ask whether the records should be here at all. ⟲
- What works today may fail tomorrow. ⟲
- **有時最好的修復是不製造問題：**把 GPS、照片和狀態歷史放在核心之外。
- 數字告訴我該看哪裡；行為告訴我該有多擔心。
- 在這個規模下，組織變化就成了資料操作。
- 規模上的修復仍然必須保留含義。
- **在圖上找出熱點：**看箭頭，問每一側會堆積多少條記錄。
- 測試你真正要設計的「零的個數」。
- **AI 會增加更多的零。**要明確地對代理程式產生的資料量建模。
- Who owns machine-created records depends on whether ownership matters for sharing. Created by and owned by aren’t the same question; decide what Owner means for each object. (Who Should Own Machine-Created Records?) ⟲
- 如果你今天不歸檔，你還會有歸檔的那一天嗎？
- **設計入口的時候，就設計出口。**每個物件五個答案：它什麼時候不再活動，去哪裡，我們如何證明，別人怎麼找到它，什麼時候刪除。
- 代理程式能否觸及歸檔資料，由業務決定。
| 術語 | 一句話解釋 |
|---|---|
| 大數據量（LDV） | 記錄多到平台的行為（而不只是數量）開始影響設計 |
| 資料傾斜 | 太多記錄集中在一個父記錄、所有人或查閱值上 |
| 父子傾斜 | 一個父記錄下的子記錄太多 |
| 所有權傾斜 | 一個使用者擁有某個物件超過大約 10,000 條記錄 |
| 查閱傾斜 | 很多活動記錄引用同一條記錄，導致鎖爭用 |
| 客戶池 | 幾個佔位父記錄分擔一個人為父記錄的子記錄 |
| Controlled by Parent | A sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain |
| Share object | The table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause |
| Big object | An object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only |
| 共用重新計算 | 所有人、角色、組或規則變化後，平台重新計算存取權限 |
| 推遲共用計算 | 等一批變化做完之後，再把重新計算只執行一次 |
| 細粒度鎖定 | 只鎖住操作所需的那部分組成員關係表 |
| 保留 | 資料儲存多久，以及為什麼 |
| 歸檔 | 把資料移出活動工作負載，同時保留業務需要的存取 |
| 清除 | 在保留期結束時永久刪除資料 |
| 三步歸檔 | 複製並標記，驗證，然後刪除並切換 |
按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。
1. 一家公司每年配送 100 萬次，每年增長 30%，保留五年。你按多大的資料量來設計？
大約 900 萬次配送，保留五年，而不是 100 萬次，然後還有它們的子記錄：按每次配送 1.6 個計算，大約 1,450 萬個明細項目；按每次配送 8 個計算，7,200 萬個狀態事件。重讀別問它今天有多大。
2. 300,000 個連絡人掛在一個叫「Unassigned Contacts」的客戶下。你怎麼做？
這是人為的父子傾斜。把連絡人分散到一個由佔位父記錄組成的客戶池裡，每個都低於閾值，並把這些佔位記錄從正常的業務視圖裡藏起來。或者問問這些連絡人到底需不需要客戶。重讀「未分配」客戶與客戶池。
3. 一個零售合作夥伴將會有 360 萬個工作訂單。有人提議建 Redrock 001、002 和 003 客戶。你怎麼看？
不行：這會破壞一個真實的業務實體。找一個業務認得出的拆分方式，比如每個配送中心一個子客戶，並歸檔已完成的配送，讓活動子記錄保持在低位。重讀Steve Trucking：熱點在哪裡？。
4. 一個整合使用者擁有 200 萬條記錄，所在的區域角色即將在重組中被移動。風險是什麼，怎麼修復？
移動它會迫使對 200 萬條記錄重新計算存取權限。不給擁有大量記錄的所有人角色，或在頂部給一個獨立、穩定的角色，讓他們不進入共用規則組，並決定對這些記錄而言所有權到底是否應該驅動存取。重讀所有權傾斜。
5. 一次重組將在一個週末裡改動幾百個角色、組和共用規則。你怎麼執行？
把它當作一次資料操作：在完整副本沙箱裡按真實資料量測試，推遲共用計算，做完所有變化，在商定的維護窗口裡只重新計算一次，然後驗證，並準備後備方案。重讀共用重新計算是真實的工作。
6. 團隊計劃用一個既複製又刪除的作業歸檔 2,000 萬條記錄。你會改什麼？
分三步：複製並標記為待處理，驗證歸檔（數量、識別符號、關係、檢索），然後刪除並切換，並設定狀態，讓在第 1,400 萬條記錄處的失敗可以安全重啟。而且在刪除任何東西之前先備份。重讀三步歸檔。
7. 客戶不希望資料存放在 Salesforce 之外，但需要保留多年的預約歷史。歸檔可以放在哪裡？
放在平台上：big object，或 Salesforce 的 Archive。用 big object 的話，先規劃好存取路徑：沒有標準介面或報表，通過索引查詢。還要讓它保持可查閱，比如在活動預約下方顯示已歸檔的預約。重讀歸檔應該放在哪裡？。
- Salesforce Certified Platform Data Architect Exam Guide （在新標籤頁中開啟）, Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- 每個模組自己的「延伸探索」部分都列出了其中事實所依據的 Salesforce 文件。