當資料量遇上共用模型

🌐 另有 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)

圖片由 AI 生成

由 AI 翻譯，尚未經過社群審閱。 閱讀英文版 本節的英文原文已有變更，尚未重新翻譯。 (35)

第 3 個模組，共 4 個，屬於 Data Architect 課程第 7 章為規模而設計。每個模組都可以單獨閱讀。 上一篇：熱點：所有權、父記錄和查閱傾斜 · 下一篇：如果你今天不歸檔……

**本模組回答的問題：**一個尊重共用的模型，如何在大數據量下保持快速？

上一個模組找到了熱點。現在加上安全，一個看起來合理的資料架構就在這裡變得昂貴。900 萬個工作訂單是資料量問題。900 萬個工作訂單，每一個都恰好對正確的內部使用者和正確的零售合作夥伴可見，就是一個大規模共用問題。一條記錄不只是被儲存；Salesforce 還必須回答**誰能看到它？**在規模上，這個答案就是資料架構的一部分。

共用也是資料

架構師計算資料量時，計算的是業務記錄。但 Salesforce 還維護著支撐存取的東西：所有人、角色、組、共用規則、顯式共用、成員關係。規模小的時候，你可以忘記這些工作的存在。規模大的時候，你忘不了。所以我從不說「共用的事以後讓安全團隊去處理」。我選擇的關係、所有人、父記錄、外部使用者模型：每一樣都影響共用。資料架構師和共用架構師可能是不同的人，但他們的架構是連在一起的。

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing （在新標籤頁中開啟）; Sharing a Record Using Apex （在新標籤頁中開啟）). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood （在新標籤頁中開啟）, Winter ‘27, archived copy （在新標籤頁中開啟）). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables. ⟲

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare （在新標籤頁中開啟）). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects. ⟲

點擊放大

Step 1 of 3: the records. Nine million work orders. ⟲

點擊放大

Step 2 of 3: the share table, three rules to groups. ⟲

點擊放大

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records. ⟲

That’s why the levers that keep sharing fast are mostly levers on the number of rows: ⟲

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source). ⟲
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs). ⟲
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3). ⟲
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below). ⟲

Test knowledge. 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. ⟲

從存取需求開始

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect. ⟲

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together. ⟲

角色階層不是組織架構圖

團隊設計角色階層時，常常照搬組織架構圖。然後公司重組，有人挪動了一個角色，Salesforce 就得算出存取上的後果。規模小時沒人注意。在幾百萬條記錄上，重組就是一次大型資料操作。所以對擁有大量記錄的所有人，指導是不給角色，或者在層級頂部給一個獨立、穩定的角色（Ownership Data Skew （在新標籤頁中開啟））。這個原則可以推廣：**在規模上，穩定性是一項設計特性。**掛在一個共用結構上的記錄越多，改動它時就要越小心。

組也一樣。公共組為共用規則提供來源；使用者屬於組；組裡包含組。這些是有用的工具，但如果大量使用者和記錄依賴不斷變化的組成員關係，你就需要理解重新計算。所以擁有大量記錄的所有人要不進入用作共用規則來源的公共組（同一來源）。教訓不是「公共組不好」。而是：不要不假思索地把你最大的記錄集中點，連到你最易變的存取結構上。

共用重新計算是真實的工作

Steve Trucking 改變了運營模式：幾百個使用者調動，所有權變化，角色和組變化，一條大的共用規則也變了。這聽起來像配置。但平台可能要對一大批記錄重新計算存取權限，所以我把它當作一次資料操作。多少使用者、多少記錄、多少所有權和成員關係的變化？要重新計算多少？能在真實資料量下測試嗎？什麼時候執行，期間使用者看到什麼？一次大型安全調整，值得和一次大型資料遷移同樣的紀律。

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance （在新標籤頁中開啟）). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale （在新標籤頁中開啟）, Winter ‘27). ⟲

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time. ⟲

點擊放大

At scale, access realignment is a data operation. ⟲

「推遲」不等於隨意。如果一個變化大到需要推遲共用計算，我就要一個計劃：在真實資料量下測試過，有業務認可的維護視窗，有驗證，有沒跑完時的後備方案，還要了解期間使用者會體驗到什麼。Salesforce 的指導是先在完整副本沙箱裡建模（同一來源），因為一個在 5,000 條測試記錄上運作得很漂亮的安全模型，對 5,000 萬條記錄什麼也證明不了。測試你真正要設計的「零的個數」。

細粒度鎖定有幫助，但不是解藥

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking （在新標籤頁中開啟）); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters. ⟲

Steve Trucking：大規模的合作夥伴隔離

在檢查點 1，每個工作訂單都持久地帶著它的零售合作夥伴，因為合作夥伴隔離是一項需求。規模數字讓這一點更重要，而不是更不重要：如果 Redrock 佔業務的 40%，五年下來就是大約 360 萬個 Redrock 工作訂單。這個關係是對的；Redrock 確實是一個合作夥伴。所以存取設計必須遵循真實的業務關係（合作夥伴使用者看到自己合作夥伴的工作訂單，配送中心經理只看到自己配送中心的），而不是扭曲模型。上一個模組裡「每個配送中心一個子客戶」的結構在這裡幫了兩次忙：它分散了子記錄，也讓配送中心級別的存取有一個真實的東西可以掛靠。

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times. ⟲

內部存取又是另一回事

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

有時安全應該改變模型。當兩類資訊的所有人、生命週期、受眾或共用需求完全不同時，你可以在一條記錄上堆砌欄位級控制，也可以把資料拆分到一個有自己邊界的獨立物件裡。我不會只為了不配置欄位級安全就拆分，但安全是改變物理模型的正當理由。

共用有它自己的「零的個數」

兩個設計，各有 1,000 萬條記錄：一個所有權簡單、層級穩定、共用規則少、成員關係變動小；另一個所有權高度分散、角色頻繁變化、巢狀的大組、大量共用規則、不斷重組。記錄數相同，規模問題卻完全不同。所以對每一個大數據量物件，我也要存取模型的數字：有多少所有人、集中程度如何、預設存取權限、哪些層級關係、規則和組起作用、有多少外部使用者，以及有人換角色、新增合作夥伴、重組一個區域時會發生什麼。然後問一個問題：**這個設計可能引發的最大一次重新計算是什麼？**這就是我要測試的場景。

點擊放大

Count the access model, not just the records. ⟲

不要為了最佳化而丟掉安全

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy. ⟲

**考試之外：AI 改變了什麼。**代理程式檢索和彙總的速度比任何人都快，這讓過於寬泛的存取模型更加危險。不要依賴一句提示詞說「不要把 Brightwave 的資料給 Redrock 看」。邊界屬於架構：應該由授權限制代理程式能觸及什麼，而不是由指令限制它選擇透露什麼。讓授權模型隨資料模型一起擴充套件。

架構師在這裡決定什麼

• 對每個大數據量物件，哪些關係、所有人、角色、組和共用規則驅動存取。
• 擁有大量記錄的所有人和其他熱點，是否與易變的層級和組結構隔離。
• 大型存取調整如何測試、安排、只重新計算一次，並在生產資料量下驗證。
• 不同的安全需求是否足以支援拆分資料，而不是讓對一條記錄的存取變得複雜。
• 合作夥伴、員工、應用和代理程式的存取，如何始終與業務關係掛鉤，而不是走身分的捷徑。

為 1,000 條記錄畫一個安全的設計很容易，畫一個人人都能看到一切的快速設計也很容易。架構師的工作是讓兩者都能存活的系統：正確的人看到正確的資料，加上那些零以後仍然運作。在規模上，共用是資料架構的一部分。

延伸探索

• Object Reference for the Salesforce Platform, WorkOrderShare （在新標籤頁中開啟） (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance （在新標籤頁中開啟） (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew （在新標籤頁中開啟）, Group Membership Locking （在新標籤頁中開啟） and Deferred Sharing Maintenance （在新標籤頁中開啟）, checked 2026-11-01. ⟲
• 深入閱讀：Sharing and Visibility Architect 課程的大規模共用 (coming soon)。
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲
• Salesforce, Record-Level Access: Under the Hood （在新標籤頁中開啟） (Winter ‘27, archived copy （在新標籤頁中開啟）), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing （在新標籤頁中開啟） and Sharing a Record Using Apex （在新標籤頁中開啟）, checked 2026-11-01. ⟲