เมื่อปริมาณพบกับโมเดลการแชร์

🌐 มีให้อ่านอีก 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 ในบท การออกแบบเพื่อรองรับขนาด บทที่ 7 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: จุดร้อน: ข้อมูลกระจุกตัวด้านความเป็นเจ้าของ เรกคอร์ดแม่ และ lookup · ถัดไป: ถ้าคุณไม่จัดเก็บถาวรวันนี้…

คำถามที่โมดูลนี้ตอบ: โมเดลที่เคารพการแชร์จะยังเร็วอยู่ได้อย่างไรเมื่อปริมาณมาก?

โมดูลที่แล้วหาจุดร้อนเจอแล้ว ทีนี้เพิ่มความปลอดภัยเข้าไป ซึ่งเป็นจุดที่สถาปัตยกรรมข้อมูลที่ดูสมเหตุสมผลกลายเป็นของแพง เก้าล้านใบสั่งงานคือปัญหาด้านปริมาณ เก้าล้านใบสั่งงานที่แต่ละใบมองเห็นได้โดยผู้ใช้ภายในที่ถูกต้องพอดีและพาร์ทเนอร์ค้าปลีกที่ถูกต้องพอดี คือปัญหาการแชร์เมื่อปริมาณมาก เรกคอร์ดไม่ได้แค่ถูกจัดเก็บ 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 คือจำลองมันก่อนใน full copy sandbox (แหล่งเดียวกัน) เพราะโมเดลความปลอดภัยที่ทำงานได้สวยงามกับเรกคอร์ดทดสอบ 5,000 รายการ ไม่ได้พิสูจน์อะไรเกี่ยวกับ 50 ล้านเลย ทดสอบที่จำนวนเลขศูนย์ที่คุณกำลังออกแบบจริงๆ

การล็อกแบบละเอียดช่วยได้ แต่ไม่ใช่ยารักษา

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% ของธุรกิจ นั่นคือประมาณ 3.6 ล้านใบสั่งงานของ Redrock ในห้าปี ความสัมพันธ์ถูกต้อง Redrock เป็นพาร์ทเนอร์รายเดียวจริงๆ ดังนั้นการออกแบบสิทธิ์เข้าถึงต้องเป็นไปตามความสัมพันธ์ทางธุรกิจจริง (ผู้ใช้ฝั่งพาร์ทเนอร์เห็นใบสั่งงานของพาร์ทเนอร์ตัวเอง ผู้จัดการ DC เห็นเฉพาะของ DC ตัวเอง) แทนที่จะบิดเบือนโมเดล โครงสร้างบัญชีลูกหนึ่งบัญชีต่อ DC จากโมดูลที่แล้วช่วยตรงนี้สองต่อ: มันกระจายเรกคอร์ดลูก และให้สิทธิ์เข้าถึงระดับ DC มีสิ่งจริงให้ยึด

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

บางครั้งความปลอดภัยควรเปลี่ยนโมเดล เมื่อข้อมูลสองประเภทมีเจ้าของ วงจรชีวิต กลุ่มผู้ดู หรือความต้องการด้านการแชร์ที่ต่างกันโดยสิ้นเชิง คุณจะซ้อนการควบคุมระดับฟิลด์ไว้บนเรกคอร์ดเดียวก็ได้ หรือแยกข้อมูลไปไว้ในออบเจกต์ของตัวเองที่มีขอบเขตของตัวเอง ผมไม่ได้แยกเพียงเพื่อเลี่ยงการตั้งค่าความปลอดภัยระดับฟิลด์ แต่ความปลอดภัยเป็นเหตุผลที่ชอบธรรมในการเปลี่ยนโมเดลทางกายภาพ

การแชร์มีจำนวนเลขศูนย์ของตัวเอง

สองการออกแบบที่มี 10 ล้านเรกคอร์ดเท่ากัน: แบบหนึ่งมีความเป็นเจ้าของที่เรียบง่าย ลำดับชั้นมั่นคง กฎการแชร์น้อย และการเปลี่ยนสมาชิกน้อย อีกแบบมีความเป็นเจ้าของที่กระจายมาก บทบาทเปลี่ยนบ่อย กลุ่มซ้อนกันขนาดใหญ่ กฎการแชร์มาก และการปรับโครงสร้างตลอดเวลา จำนวนเรกคอร์ดเท่ากัน แต่ปัญหาด้านขนาดต่างกันโดยสิ้นเชิง ดังนั้นสำหรับออบเจกต์ปริมาณมากทุกตัว ผมต้องการตัวเลขของโมเดลสิทธิ์เข้าถึงด้วย: มีเจ้าของกี่คนและกระจุกตัวแค่ไหน สิทธิ์เข้าถึงเริ่มต้น ความสัมพันธ์ในลำดับชั้น กฎ และกลุ่มไหนที่มีผล ผู้ใช้ภายนอกกี่คน และเกิดอะไรขึ้นเมื่อมีคนเปลี่ยนบทบาท มีพาร์ทเนอร์ถูกเพิ่ม หรือภูมิภาคถูกปรับโครงสร้าง แล้วถามคำถามเดียว: การคำนวณใหม่ที่ใหญ่ที่สุดที่การออกแบบนี้อาจก่อให้เกิดคืออะไร? นั่นคือสถานการณ์ที่ผมอยากให้ทดสอบ

คลิกเพื่อขยาย

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 เปลี่ยนอะไร เอเจนต์ดึงและรวบรวมข้อมูลได้เร็วกว่าคนใดๆ ซึ่งทำให้โมเดลสิทธิ์เข้าถึงที่กว้างเกินไปอันตรายยิ่งขึ้น อย่าพึ่งพา prompt ที่บอกว่า “อย่าแสดงข้อมูลของ Brightwave ให้ Redrock” ขอบเขตควรอยู่ในสถาปัตยกรรม: การอนุญาตควรจำกัดสิ่งที่เอเจนต์เข้าถึงได้ ไม่ใช่คำสั่งว่ามันเลือกจะเปิดเผยอะไร จงขยายโมเดลการอนุญาตไปพร้อมกับโมเดลข้อมูล

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• ความสัมพันธ์ เจ้าของ บทบาท กลุ่ม และกฎการแชร์ใดที่ขับเคลื่อนสิทธิ์เข้าถึงสำหรับออบเจกต์ปริมาณมากแต่ละตัว
• เจ้าของที่ถือเรกคอร์ดปริมาณมากและจุดร้อนอื่นๆ ถูกแยกออกจากโครงสร้างลำดับชั้นและกลุ่มที่ผันผวนหรือไม่
• การจัดโครงสร้างสิทธิ์เข้าถึงใหม่ครั้งใหญ่ถูกทดสอบ กำหนดเวลา คำนวณใหม่ครั้งเดียว และตรวจยืนยันที่ปริมาณ production อย่างไร
• ความต้องการด้านความปลอดภัยที่ต่างกันเป็นเหตุผลให้แยกข้อมูล แทนที่จะทำให้สิทธิ์เข้าถึงเรกคอร์ดเดียวซับซ้อนขึ้นหรือไม่
• สิทธิ์เข้าถึงของพาร์ทเนอร์ พนักงาน แอปพลิเคชัน และเอเจนต์ยังผูกอยู่กับความสัมพันธ์ทางธุรกิจได้อย่างไร ไม่ใช่ทางลัดด้านตัวตน

วาดการออกแบบที่ปลอดภัยสำหรับ 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. ⟲