ความเป็นเจ้าของและวงจรชีวิต

🌐 มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 8 จาก 10 ในบท สถาปัตยกรรมข้อมูล Salesforce บทที่ 3 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ความสัมพันธ์มีผลตามมา · ถัดไป: รักษาข้อมูลให้สอดคล้องกัน

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

เมื่อผมดูโมเดลข้อมูล ผมไม่ได้อยากรู้แค่ว่าออบเจกต์คืออะไรและเชื่อมกันอย่างไร ผมอยากรู้ว่าจะเกิดอะไรขึ้นกับเรกคอร์ดเมื่อเวลาผ่านไป ใครสร้างมัน? ใครเป็นเจ้าของ? ใครมอบหมายใหม่ได้? จะเกิดอะไรขึ้นเมื่อความสัมพันธ์ทางธุรกิจเปลี่ยน เมื่อมันไม่ได้ใช้งานแล้ว? ควรถูกลบไหม และเราเก็บมันไว้นานเท่าไร? ไม่มีสิ่งใดในนั้นปรากฏบน ERD (entity relationship diagram) ซึ่งคือกล่องและเส้นของโมเดลข้อมูลในบทที่ 2 แต่ทั้งหมดคือสถาปัตยกรรมข้อมูล และบน Salesforce ความเป็นเจ้าของคือที่ที่โมเดลข้อมูลกับโมเดลความปลอดภัยมาชนกัน

ความเป็นเจ้าของเป็นมากกว่าชื่อในฟิลด์

ผู้ดูแลระบบเห็น Owner บนเรกคอร์ดแล้วอ่านเป็นป้ายชื่อ: Bart เป็นเจ้าของบัญชีนี้ Lisa เป็นเจ้าของเคสนั้น มันหมายถึงแบบนั้นได้ แต่บน Salesforce ความเป็นเจ้าของยังเป็นกลไกของแพลตฟอร์มด้วย บนออบเจกต์ที่มีเจ้าของ เจ้าของเป็นตัวกำหนดว่าใครเห็นเรกคอร์ดได้ ผ่านลำดับชั้นบทบาท กฎการแชร์ คิว และการมอบหมายใหม่ ดังนั้นเมื่อผมถามว่า “ใครเป็นเจ้าของเรกคอร์ดนี้?” ผมไม่ได้ถามว่าชื่อใครอยู่บนหน้า ผมถามว่าเรากำลังผูกพฤติกรรมด้านความปลอดภัยและวงจรชีวิตอะไรเข้ากับมัน เจ้าของเป็นผู้ใช้ได้ หรือสำหรับบางออบเจกต์ ซึ่งรวมถึงออบเจกต์ที่กำหนดเอง เคส และลูกค้าเป้าหมาย เป็นคิวก็ได้ และไม่ว่าแบบไหน เจ้าของได้สิทธิ์เข้าถึงเรกคอร์ดเต็มที่ (Understanding Sharing (opens in a new tab) ภาษาอังกฤษ)

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

Share Table: ที่ที่ความเป็นเจ้าของกลายเป็นสิทธิ์เข้าถึง

บางคนไม่รู้ด้วยซ้ำว่า share table คืออะไร สถาปนิกข้อมูลทุกคนควรรู้

การแชร์ส่วนใหญ่ของเรกคอร์ดหนึ่งถูกเก็บไว้ใน share object ที่เกี่ยวข้อง ซึ่งเป็นรายการควบคุมการเข้าถึง (access control list) ในแบบของ Salesforce (Understanding Sharing (opens in a new tab) ภาษาอังกฤษ) บัญชีมี AccountShare ผู้ติดต่อมี ContactShare และออบเจกต์ที่กำหนดเองก็ได้ของตัวเอง: Truck__c มี Truck__Share (Sharing a Record Using Apex (opens in a new tab) ภาษาอังกฤษ) แต่ละแถวในนั้นบอกสี่อย่าง:

• เรกคอร์ดไหน: ID ของแม่ (parent ID)
• ใคร: ผู้ใช้ หรือกลุ่ม (กลุ่มสาธารณะ กลุ่มของบทบาท เขตการขาย)
• มากแค่ไหน: Read, Edit หรือ All (สิทธิ์เต็ม)
• ทำไม: row cause (เหตุผลของแถว) Owner สำหรับเจ้าของ Rule สำหรับกฎการแชร์ Manual สำหรับการแชร์ด้วยตนเอง Team เหตุผลโดยนัยที่ Salesforce เพิ่มระหว่างบัญชีกับลูกของมัน และเหตุผลที่นักพัฒนากำหนดเองสำหรับการแชร์ด้วย Apex

ในคลาสผมเปิด Workbench แล้วคิวรี share table ขณะที่ผมแชร์เรกคอร์ด แล้วคุณก็ดูแถวโผล่ขึ้นมาและหายไป เมื่อมีคนถามว่า “ทำไมคนนี้เห็นสิ่งนั้นได้?” คำตอบมักนั่งอยู่ในแถวหนึ่ง พร้อมเหตุผลของมัน

แต่ไม่ใช่ทุกอย่างอยู่ในนั้น ค่าเริ่มต้นทั้งองค์กร (organization-wide default) ไม่ใช่แถว ลำดับชั้นบทบาทก็ไม่ได้ถูกเก็บไว้ที่นั่นเช่นกัน: สิทธิ์เข้าถึงของคนที่อยู่เหนือเจ้าของถูกคำนวณเมื่อจำเป็น และ View All, Modify All, View All Data และ Modify All Data ข้าม share table ไปเลย (Sharing a Record Using Apex (opens in a new tab) ภาษาอังกฤษ) อย่างที่ผมพูดในคลาส: ติ๊ก View All แล้วคุณก็ข้าม share table ไปแล้ว

Salesforce ยังแชร์บางเรกคอร์ดให้คุณด้วย เพราะวิธีที่มันเกี่ยวข้องกัน นี่คือการแชร์โดยนัย (implicit sharing) และมันทำงานระหว่างบัญชีกับลูกของมัน ถ้าคุณเห็นผู้ติดต่อ เคส หรือโอกาสทางการขาย คุณก็อ่านบัญชีที่มันสังกัดได้ด้วย และเจ้าของบัญชีได้สิทธิ์เข้าถึงผู้ติดต่อ เคส และโอกาสทางการขายของบัญชี ในระดับที่กำหนดโดยบทบาทของเจ้าของ (Implicit Sharing (opens in a new tab) ภาษาอังกฤษ) ในรีลีสล่าสุด Salesforce คำนวณสิทธิ์เข้าถึงลูกบางส่วนเมื่อจำเป็น แทนที่จะเก็บเป็นแถว ดังนั้นอย่าแปลกใจเมื่อคิวรี share table แล้วไม่เห็นมัน ผมแค่ให้คำใบ้ตรงนี้ รายละเอียดอยู่ในความสัมพันธ์และการแชร์ที่มีมาในตัว

ข้อยกเว้นอีกข้อหนึ่ง สำหรับเมื่อคุณมีผู้ใช้ภายนอกจำนวนมาก ผู้ใช้ชุมชนปริมาณสูง (high-volume community users) ซึ่งคือสิทธิ์ Customer Community ที่สร้างมาสำหรับลูกค้าหลายพันถึงหลายล้านราย ไม่มีบทบาท อยู่ในกลุ่มสาธารณะไม่ได้ และรับเรกคอร์ดผ่านกฎการแชร์หรือการแชร์ด้วยตนเองไม่ได้ (About High-Volume Community or Site Users (opens in a new tab) ภาษาอังกฤษ; Sharing Rule Considerations (opens in a new tab) ภาษาอังกฤษ) สำหรับพวกเขา share table ไม่ใช่คำตอบ: พวกเขาเข้าถึงเรกคอร์ดผ่าน sharing set ซึ่งจับคู่บัญชีหรือผู้ติดต่อของเรกคอร์ดกับของผู้ใช้เอง นี่เป็นหนึ่งในเหตุผลที่สิทธิ์เหล่านั้นรองรับขนาดได้ หลักสูตร Sharing and Visibility พูดถึงเรื่องนี้ในการแชร์กับผู้ใช้ภายนอก

และจำโมดูลที่ 7 ไว้: ออบเจกต์ detail ไม่มี share object เลย สิทธิ์เข้าถึงของมันมาจาก share object ของ master และ Sharing Setting บนฟิลด์ master-detail

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

ความรู้ที่ออกสอบ share object ของออบเจกต์ที่กำหนดเองชื่อว่า Object__Share เช่น Truck__Share ออบเจกต์ detail ไม่มี share object: สิทธิ์เข้าถึงของมันมาจาก master และเมื่อเจ้าของเรกคอร์ดเปลี่ยน การแชร์ด้วยตนเองจะถูกลบ ขณะที่การแชร์ด้วย Apex ที่มีเหตุผลซึ่งนักพัฒนากำหนดเองยังอยู่

นี่คือจุดที่โมเดลข้อมูลส่งต่อให้โมเดลความปลอดภัย และผมสอนส่วนที่เหลือในหลักสูตร Sharing and Visibility Architect: 22 วิธีแชร์เรกคอร์ดของ Steve ค่าเริ่มต้นทั้ง org ความเป็นเจ้าของ คิว และลำดับชั้นบทบาท ความสัมพันธ์และการแชร์ที่มีมาในตัว สำหรับการแชร์โดยนัย และการแชร์ด้วยโปรแกรมและโค้ดที่ปลอดภัย สำหรับเหตุผลการแชร์ด้วย Apex ในหลักสูตรนี้ บทที่ 12 จะรวมทั้งหมดเข้าด้วยกันสำหรับคน แอปพลิเคชัน และเอเจนต์

บางครั้งความเป็นเจ้าของถูกสืบทอด

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

ใครเป็นเจ้าของเรกคอร์ดที่ระบบสร้าง?

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

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

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

ความเป็นเจ้าของกลายเป็นปัญหาด้านขนาดได้

การกระจายก็สำคัญ สิบล้านเรกคอร์ดที่กระจายไปยังเจ้าของหลายพันคนเป็นรูปร่างหนึ่ง สิบล้านเรกคอร์ดที่ผู้ใช้คนเดียวเป็นเจ้าของเป็นอีกรูปร่างที่ต่างมาก Salesforce เรียกสิ่งนี้ว่า ownership data skew (ความเป็นเจ้าของกระจุกตัว) เมื่อผู้ใช้คนเดียวเป็นเจ้าของมากกว่า 10,000 เรกคอร์ดของออบเจกต์หนึ่ง (Ownership Data Skew (opens in a new tab) ภาษาอังกฤษ) มักเกิดเมื่อมีคนจอดทุกอย่างไว้กับผู้ใช้หรือคิวเดียว: ลูกค้าเป้าหมายที่ยังไม่ได้มอบหมายทั้งหมดอยู่กับผู้ใช้ตัวยึดตำแหน่ง ทุกเรกคอร์ดการผสานรวมอยู่กับผู้ใช้การผสานรวม มันไม่มีพิษภัยจนกว่าผู้ใช้นั้นจะย้ายในลำดับชั้นบทบาท หรือเข้าหรือออกจากกลุ่มที่กฎการแชร์พึ่งพา แล้ว Salesforce ต้องปรับรายการการแชร์จำนวนมหาศาล และคุณจะเจอการคำนวณใหม่ที่ใช้เวลานาน

แนวทางนั้นใช้ได้จริง กระจายความเป็นเจ้าของไปยังผู้ใช้มากขึ้นเมื่อทำได้ ถ้าผู้ใช้คนหนึ่งต้องเป็นเจ้าของจำนวนมาก ให้เก็บเขาไว้นอกลำดับชั้นบทบาท ถ้าเขาต้องมีบทบาท ให้วางเขาไว้ในบทบาทของตัวเองที่ด้านบนสุดและอย่าย้ายเขา และเก็บเขาไว้นอกกลุ่มสาธารณะที่กฎการแชร์ใช้ (Ownership Data Skew (opens in a new tab) ภาษาอังกฤษ) วิธีคิดเดียวกันใช้กับแม่ที่มีลูกมากเกินไปจากโมดูลที่แล้ว parent-child skew

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

“เจ้าของค่าเริ่มต้น” กลายเป็นสถาปัตยกรรม

นี่คือรูปแบบที่ผมเห็นตลอด ไม่มีใครรู้ว่าใครควรเป็นเจ้าของอะไรบางอย่าง จึงมีคนพูดว่า “มอบหมายทั้งหมดให้ผู้ใช้การผสานรวมไปเลย” หรือ “สร้างผู้ใช้กลางชื่อ System” บางทีนั่นอาจถูก แต่อย่าทำโดยบังเอิญ ค่าเริ่มต้นชั่วคราวมีนิสัยกลายเป็นถาวร: สองปีต่อมาทุกเรกคอร์ดเป็นของ integration@company.com ไม่มีใครจำได้ว่าทำไม และการเปลี่ยนมันคือโปรเจกต์หนึ่ง นั่นคือการทดสอบความย้อนกลับได้ของบทที่ 1: ก่อนให้เรกคอร์ดหนึ่งล้านรายการแก่เจ้าของคนเดียว ถามว่าการเปลี่ยนมันทีหลังต้องใช้อะไรบ้าง

การมอบหมายใหม่คือเหตุการณ์ในวงจรชีวิต

เจ้าของเปลี่ยน พนักงานขายลาออก เขตการขายย้าย ทีมปรับโครงสร้าง ภูมิภาคถูกจัดสมดุลใหม่ อะไรพึ่งพาเจ้าของบ้าง: การแชร์ ระบบอัตโนมัติ รายงาน คิว การยกระดับ การผสานรวม? ถ้าการเปลี่ยนเจ้าของเปลี่ยนว่าใครเห็นเรกคอร์ดได้ การมอบหมายใหม่ก็ไม่ใช่งานเก็บกวาดของผู้ดูแลระบบ มันคือเหตุการณ์ด้านความปลอดภัย และที่หนึ่งล้านเรกคอร์ด มันเป็นเหตุการณ์เชิงปฏิบัติการด้วย ดู share table ตอนที่มันเกิดขึ้น: การแชร์ด้วยตนเองจะถูกลบเมื่อเจ้าของเปลี่ยน ขณะที่การแชร์ด้วย Apex ที่มีเหตุผลซึ่งนักพัฒนากำหนดเองรอดจากการเปลี่ยนนั้น (Understanding Sharing (opens in a new tab) ภาษาอังกฤษ) ในคลาสผมแชร์เรกคอร์ดให้ใครสักคน เปลี่ยนเจ้าของ แล้วคนนั้นก็เสียสิทธิ์เข้าถึง คนในห้องประหลาดใจทุกครั้ง

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

การสร้างเป็นแค่จุดเริ่มต้น

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

Click to enlarge

อย่าลบเพียงเพราะบางอย่างเก่า

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

การเก็บรักษาคือความต้องการทางธุรกิจ

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

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

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

Steve Trucking: ใครเป็นเจ้าของการจัดส่ง?

การจัดส่งถูกสร้างจากใบรายการสินค้าของพันธมิตรค้าปลีก โดยการผสานรวม ราว 3,300 ครั้งต่อวัน ใครเป็นเจ้าของ? ไม่ใช่พันธมิตรค้าปลีก นั่นเป็นความสัมพันธ์ทางธุรกิจ ไม่ใช่ผู้รับ ทีมจัดส่งเป็นผู้ปฏิบัติ แต่เรกคอร์ดควรเปลี่ยนเจ้าของทุกครั้งที่ทีมสลับรถไหม? ผู้จัดการเดินรถ? ศูนย์กระจายสินค้า? คิว? ผู้ใช้การผสานรวมที่สร้างมัน?

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

คำตอบของผมจึงเป็น: ผู้ใช้การผสานรวมเป็นเจ้าของการจัดส่ง นี่เป็นตัวอย่างที่ดีของผู้ใช้ระบบที่เป็นเจ้าของเรกคอร์ดอย่างตั้งใจ:

• ร่องรอยการตรวจสอบซื่อตรง เจ้าของของทุกการจัดส่งบอกว่ามันมาจากไหน: การผสานรวมใบรายการสินค้า
• สิทธิ์เข้าถึงมาจากการแชร์ ไม่ใช่ความเป็นเจ้าของ กฎการแชร์แบบอิงเกณฑ์บนศูนย์กระจายสินค้าให้ทีมของ DC แต่ละแห่งเห็นการจัดส่งของตน พันธมิตรเข้าถึงของตัวเองผ่านพอร์ทัล
• skew ถูกออกแบบให้หมดไป ที่ 3,300 ต่อวัน ผู้ใช้การผสานรวมจะเกิน 10,000 การจัดส่งในสามวัน จึงเป็น ownership skew ตั้งแต่วันแรก และนั่นไม่เป็นไรถ้าเราวางแผนรับไว้ ผู้ใช้การผสานรวมไม่มีบทบาท จึงไม่มีอะไรเหนือมันในลำดับชั้นที่ต้องคำนวณใหม่ และมันอยู่นอกกลุ่มสาธารณะที่กฎการแชร์ของเราใช้
• ไม่มีใครมอบหมายการจัดส่งใหม่ ทีมจัดส่งสลับรถ ผู้จัดการเดินรถเปลี่ยนกะ แต่เจ้าของไม่เคยย้าย จึงไม่มีพายุการมอบหมายใหม่ และไม่มีการแชร์ด้วยตนเองที่จะหายไป

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

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร เอเจนต์สร้างและเปลี่ยนเรกคอร์ดด้วยความเร็วของเครื่องจักร ถ้าเอเจนต์สร้าง 100,000 เรกคอร์ดภายใต้ผู้ใช้ของตัวเอง “เดี๋ยวค่อยแก้เจ้าของทีหลัง” จะกลายเป็น skew การคำนวณการแชร์ใหม่ และโปรเจกต์เก็บกวาด ตัดสินกฎความเป็นเจ้าของของเอเจนต์ก่อนที่มันจะใช้งานจริง ด้วยคำถามเดิม: ที่นี่ความเป็นเจ้าของมีผลต่อการแชร์หรือไม่?

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

• ความเป็นเจ้าของแทนความรับผิดชอบทางธุรกิจ กลไกความปลอดภัย หรือทั้งสองอย่าง และความรับผิดชอบอยู่ที่ไหนถ้าไม่อยู่ใน Owner
• เรกคอร์ดต้องมีเจ้าของของตัวเอง หรือควรสืบทอดจากแม่
• ใครเป็นเจ้าของเรกคอร์ดที่การผสานรวมและเอเจนต์สร้าง ขึ้นอยู่กับว่าความเป็นเจ้าของขับเคลื่อนการแชร์หรือไม่
• ความเป็นเจ้าของกระจายอย่างไร และจะหลีกเลี่ยง ownership skew อย่างไรเมื่อผู้ใช้คนหนึ่งต้องเป็นเจ้าของจำนวนมาก
• เมื่อไรเรกคอร์ดเลิกใช้งาน เมื่อไรถูกเก็บถาวร เก็บไว้นานเท่าไร และเมื่อไรการลบจึงถูกต้อง

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

ศึกษาเพิ่มเติม

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13): เจ้าของ (ผู้ใช้ หรือคิวสำหรับออบเจกต์ที่กำหนดเอง เคส และลูกค้าเป้าหมาย) ได้สิทธิ์เต็ม การแชร์ส่วนใหญ่อยู่ใน sharing object ที่เกี่ยวข้อง ลำดับชั้นบทบาทถูกคำนวณตอนรันไทม์ การแชร์ด้วยตนเองถูกลบเมื่อเจ้าของเปลี่ยน ส่วน Apex managed sharing ยังอยู่ และค่าของ row cause
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13): AccountShare, MyCustomObject__Share ออบเจกต์ detail ไม่มี sharing object สิ่งที่ share object ไม่ได้ติดตาม (OWD ลำดับชั้นบทบาท View All และ Modify All)
• Salesforce Help, Implicit Sharing (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13): สิทธิ์เข้าถึงระหว่างบัญชีกับผู้ติดต่อ เคส และโอกาสทางการขายของมัน
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) และ Sharing Rule Considerations (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13): ไม่มีบทบาท ไม่มีกฎการแชร์หรือการแชร์ด้วยตนเอง ใช้ sharing set แทน
• หลักสูตร Sharing and Visibility Architect: 22 วิธีแชร์เรกคอร์ดของ Steve ค่าเริ่มต้นทั้ง org ความเป็นเจ้าของ คิว และลำดับชั้นบทบาท ความสัมพันธ์และการแชร์ที่มีมาในตัว การแชร์ด้วยโปรแกรมและโค้ดที่ปลอดภัย การแชร์กับผู้ใช้ภายนอก การแชร์ในระดับขนาดใหญ่
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) และ Parent-Child Data Skew (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)