ข้อมูลนี้อยู่ที่ไหน?

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 4 จาก 10 ในบท สถาปัตยกรรมข้อมูล Salesforce บทที่ 3 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: สร้างเอง: ออบเจกต์ที่กำหนดเอง · ถัดไป: เลือกออบเจกต์ให้ถูก

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

ขอถามคำถามหนึ่ง มีความต้องการใหม่วางอยู่บนโต๊ะคุณ คุณทำอะไรเป็นอย่างแรก?

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

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

บน core และนอก core

ก่อนอื่น คำหนึ่งที่ผมจะใช้บ่อย: core core คือแพลตฟอร์ม Salesforce ที่ org ของคุณทำงานอยู่: แพลตฟอร์มแบบ multitenant ที่ขับเคลื่อนด้วยเมทาดาทาจากโมดูลที่ 1 ที่ที่ออบเจกต์ของ Sales และ Service จากโมดูลที่ 2 อยู่ รวมถึงออบเจกต์ที่กำหนดเองทุกตัวที่คุณสร้างในโมดูลที่ 3 เมื่อผมบอกว่าข้อมูลอยู่บน core ผมหมายถึงมันถูกเก็บใน org ของคุณ ในออบเจกต์ของมัน

ไม่ใช่ข้อมูลทั้งหมดที่อยู่ตรงนั้น Data 360 เก็บข้อมูลของมันในที่เก็บของตัวเอง นอกออบเจกต์ของ org คุณ (มันเป็น near-core (ใกล้ core): จัดการบน core แต่ข้อมูลโฮสต์อยู่นอก core ดูเพิ่มเติมในบทที่ 4) แล้วก็ยังมีทุกอย่างที่บริษัทของคุณใช้งานซึ่งไม่ใช่ Salesforce เลย: ERP คลังข้อมูล ระบบคำสั่งซื้อ แพลตฟอร์มของพันธมิตร ทั้งหมดนั้นอยู่นอก core Salesforce เข้าถึงมันได้ แสดงมันได้ และใช้มันได้ แต่ org ของคุณไม่ได้เก็บมัน

บน core มีออบเจกต์สองประเภทที่เก็บเรกคอร์ดของคุณจริงๆ: sObject ทั้งมาตรฐานและกำหนดเอง (__c) และ big object (__b) นอก core คุณเข้าถึงข้อมูลผ่านออบเจกต์ภายนอก (__x) และเครื่องมือการผสานรวมอื่นๆ จำคำต่อท้ายจากโมดูลที่ 3 ไว้ มันบอกคุณได้ว่าข้อมูลชิ้นหนึ่งอยู่ที่ไหนแค่จากชื่อ

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

1. บน core: มันอยู่บนโต๊ะของคุณ

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

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

2. อ้างอิง (referenced): มันอยู่ในตู้เอกสารของคนอื่น

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

นั่นคือออบเจกต์ภายนอก (external object) ผ่าน Salesforce Connect ผมชอบพูดว่ามันหน้าตาเหมือนเป็ด เดินเหมือนเป็ด แต่ไม่ใช่เป็ด มันปรากฏเหมือน sObject: คุณวางมันบนเลย์เอาต์หน้าและ related list ได้ และเชื่อมมันกับเรกคอร์ดของคุณเองด้วย external lookup และ indirect lookup ได้ แต่ข้อมูลไม่ได้ถูกเก็บบน core ทุกครั้งที่คุณแตะมัน มันจะเรียกออกไปภายนอก (callout) เปิดเรกคอร์ด โหลด related list รันรายงาน แล้ว Salesforce ก็ไปถามอีกระบบ นั่นหมายถึงความหน่วง และหน้าของคุณพร้อมใช้งานได้เท่ากับระบบที่อยู่เบื้องหลังเท่านั้น

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

เอกสารก็อ้างอิงได้เช่นกัน ถ้าสัญญาอยู่ใน SharePoint Online, OneDrive, Google Drive หรือ Box อยู่แล้ว Files Connect ช่วยให้ผู้ใช้เข้าถึงมันจาก Salesforce ได้โดยไม่ต้องคัดลอกเข้ามา

Salesforce Connect ไม่ใช่วิธีเดียวในการอ้างอิงข้อมูล บางครั้งมันคือตรรกะที่เขียนเอง (custom logic): โค้ดที่เรียกอีกระบบแบบเรียลไทม์และแสดงข้อมูลของมันบนหน้า โดยไม่เก็บสำเนาไว้ นั่นให้การควบคุมเต็มที่แก่คุณ และความรับผิดชอบเต็มที่ต่อ callout ข้อผิดพลาด และการดูแลรักษา และ Data 360 ก็ทำ federation ได้โดยไม่ต้องคัดลอกเช่นกัน ตัวเลือกนั้นมีบทของมันเอง (Virtualization, Federation และ Zero-Copy) ที่นี่ ประเด็นคือตัวการตัดสินใจ: อ้างอิง อย่าคัดลอก

3. เก็บถาวร (archived): มันไปอยู่ในโรงเก็บของหลังบ้าน

ประวัติ บันทึกการตรวจสอบ ธุรกรรมเก่า คุณต้องเก็บมัน บางครั้งหลายปี แต่แทบไม่มีใครเปิดมัน และนี่คือเรื่องที่ทีมมักเลื่อนออกไป เมื่อคลาสบอกผมว่ามีออบเจกต์ที่มี 50 ล้านเรกคอร์ดแล้วถามว่าทำไมต้องเก็บถาวร ผมถามกลับว่า: ถ้าคุณไม่เก็บถาวรวันนี้ คุณจะได้เก็บถาวรไหม? ที่ 50 ล้านวันนี้ คุณกำลังมุ่งไปที่ 100, 150, 200 ล้าน

มีโรงเก็บของสองแห่ง แห่งหนึ่งอยู่บน core: big object ให้คิดว่ามันคือการเก็บข้อมูลไว้ในโรงรถ คุณเก็บเรกคอร์ดได้จำนวนมหาศาล แต่วางมันบนเลย์เอาต์หน้าไม่ได้ ไม่มี UI หรือรายงานมาตรฐาน และคุณคิวรีผ่านอินเด็กซ์ของ big object ด้วยการตรงกันพอดีหรือช่วงค่า (Big Objects Best Practices (opens in a new tab)) ความปลอดภัยมีแค่สิทธิ์ระดับออบเจกต์และฟิลด์ ไม่มีการแชร์ระดับเรกคอร์ด และระบบอัตโนมัติไม่ทำงานบนมัน ผมใช้ Salesforce Connect มาหลายสิบครั้ง แต่ใช้ big object แค่หนึ่งหรือสองครั้ง มันใช้ได้ แต่เก้งก้าง และผมเขียนวิธีแก้ทางเพื่อเข้าถึงข้อมูลมาไม่น้อย ดังนั้นคำแนะนำของผมคือ: ทำต้นแบบก่อนจะเสนอมัน และวางแผนว่าคนจะหาข้อมูลอย่างไรก่อนเลือกมัน

โรงเก็บของอีกแห่งอยู่นอก core: คลังข้อมูลหรือฐานข้อมูลที่อื่น (การออกแบบเพื่อรองรับขนาด) บ่อยครั้งนั่นคือโรงเก็บของที่ดีกว่า และมันไม่จำเป็นต้องอยู่ลับตา ข้อมูลที่เก็บถาวรนอก core ยังปรากฏในรายงานได้ผ่านเครื่องมืออย่าง Tableau และยังเข้าถึงได้จาก Salesforce ผ่าน Salesforce Connect หรือวิธีอื่นในการทำให้มันเป็นข้อมูลเสมือน เมื่อมีคนต้องการมองย้อนกลับไป

ขอเล่าเรื่องโปรเจกต์ที่เราทำเรื่องนี้ถูกตั้งแต่แรก ลูกค้าค้าปลีกรายหนึ่งมีสถานที่กว่า 1,200 แห่ง พวกเขาบอกผมว่า “เรามีนัดหมายแค่วันละร้อยรายการต่อสาขา ไม่ใช่เรื่องใหญ่” แล้วผมก็คำนวณ: วันละร้อย สัปดาห์ละหกวัน (ประมาณ 305 วันต่อปี) คูณ 1,200 แห่ง คือนัดหมายกว่า 36 ล้านรายการต่อปี แล้วพวกเขาก็บอกว่าการมาแต่ละครั้งสร้างนัดหมายสองรายการ หนึ่งที่เคาน์เตอร์หน้าร้าน และหนึ่งสำหรับหลังร้าน: กว่า 73 ล้านเรกคอร์ดต่อปี แล้วพวกเขาก็ต้องการประวัติห้าปี: มากกว่า 360 ล้านเรกคอร์ด ก่อนจะคิดการเติบโตใดๆ เรายังไม่ได้ go-live แต่ผมเห็นรถไฟกำลังมุ่งตรงไปยังสถานีข้อมูลปริมาณมากแล้ว ระบบเก็บถาวรจึงถูกสร้างก่อนเราจะเก็บนัดหมายสักรายการ: นัดหมายเก่าย้ายไปที่ big object และหน้าค้นหาแสดงนัดหมายปัจจุบัน โดยมีรายการที่เก็บถาวรอยู่ข้างล่าง หลายปีต่อมา มันยังทำงานได้ดี

Click to enlarge

นำไปใช้: Steve Trucking

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

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

นี่คือสิ่งเดียวกันในรูปโมเดลข้อมูล การจัดส่งอยู่บน core ที่ที่คนทำงานกับมันทั้งวัน เมื่อผ่านไปสามปี มันย้ายไปที่ Delivery History ซึ่งเป็น big object: ยังอยู่บน core แต่ไปอยู่ในโรงเก็บของ คำสั่งซื้อของพันธมิตรปรากฏเป็นออบเจกต์ภายนอก __x: Salesforce เชื่อมการจัดส่งเข้ากับมัน แต่ข้อมูลยังอยู่ในระบบของร้านค้าปลีก และรูปถ่ายอยู่นอก core ทั้งหมด โดยมีลิงก์จากการจัดส่ง โมเดลเดียว บ้านสามหลัง

Click to enlarge

ทุก org จริงมีครบทั้งสามแบบ org ที่เจอปัญหาคือ org ที่วางทุกอย่างไว้บน core เพราะการสร้างออบเจกต์คือปุ่มค่าเริ่มต้น

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

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

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

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

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-09-25)
• ในหลักสูตรนี้: Virtualization, Federation, and Zero-Copy และ Designing for Scale