โมเดลข้อมูลมาตรฐาน

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

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

คำถามที่โมดูลนี้ตอบ: Salesforce สร้างโมเดลอะไรไว้ให้คุณแล้ว และมันประกอบกันอย่างไร?

ในโมดูลที่ 1 ผมบอกให้คุณมองไปที่ยานแม่: ก่อนจะประดิษฐ์อะไรขึ้นมา ให้ดูว่า Salesforce เองทำมันอย่างไร โมดูลนี้คือที่ที่เรามองจริงๆ Salesforce สร้างโมเดลของธุรกิจไว้ให้คุณมากมายแล้ว ในออบเจกต์มาตรฐานของมัน และมีสองโมเดลที่ทำงานส่วนใหญ่ใน org ส่วนใหญ่ที่ผมเข้าไปดู: โมเดลการขาย (Sales) และโมเดลการบริการ (Service) ก่อนที่คุณจะตัดสินได้ว่าบางอย่างสมควรเป็นออบเจกต์ที่กำหนดเองไหม คุณต้องรู้ว่ามีอะไรอยู่แล้ว นั่นคือเรื่องของสองโมดูลถัดไป

อะไรทำให้ออบเจกต์เป็นออบเจกต์มาตรฐาน

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

ดูที่ชื่อ Account, Contact, Case ไม่มีคำนำหน้า ไม่มีคำต่อท้าย นั่นคือ Salesforce สงวนพื้นที่นั้นไว้ให้ตัวเอง ทุกอย่างที่เราสร้างลงท้ายด้วย __c Salesforce จึงเพิ่มออบเจกต์มาตรฐานใหม่ได้ทุกเมื่อโดยไม่ชนกับอะไรใน org ของคุณเลย และมันก็ทำแบบนั้นทุกรีลีส

ที่ไหนสักแห่งระหว่างทาง มีคนสร้างออบเจกต์สินค้าที่ไม่เวิร์กและต้องถูกทิ้งไว้ข้างหลัง นั่นคือเหตุผลที่ API name คือ Product2 มันเป็นบททดสอบแรกของผมเมื่อมีคนบอกว่ารู้จัก Salesforce

โมเดลการขาย

เริ่มทางซ้าย กับลูกค้าเป้าหมาย (Lead): คนที่อาจกลายเป็นลูกค้า ลูกค้าเป้าหมายยังไม่ได้เป็นส่วนหนึ่งของโมเดลจริงๆ มันเป็นพื้นที่พักรอ เมื่อคุณแปลงมัน Salesforce จะสร้างเรกคอร์ดจริงขึ้นมา: บัญชี (Account) ผู้ติดต่อ (Contact) และถ้ามีดีล ก็โอกาสทางการขาย (Opportunity) นั่นคือเหตุผลที่ผมวาดลูกค้าเป้าหมายไว้ด้านข้าง

บัญชีคือบริษัท ผู้ติดต่อของมันคือคนในบริษัทนั้น โอกาสทางการขายคือดีลกับบัญชีนั้น จนถึงตอนนี้ ไม่มีอะไรที่คุณไม่ได้คาดไว้

แล้วมันก็เริ่มน่าสนใจ ในดีลมีอะไร? แต่ละบรรทัดคือ Opportunity Product (สินค้าในโอกาสทางการขาย) และ Opportunity Product ไม่ได้ชี้ไปที่ Product โดยตรง มันชี้ไปที่ Price Book Entry (รายการในสมุดราคา): สินค้านี้ ในราคานี้ ในสมุดราคาเล่มนี้ Price Book Entry อยู่ระหว่าง Product (สินค้า) กับ Price Book (สมุดราคา) สินค้าเดียวกันจึงมีราคาหนึ่งในสมุดราคามาตรฐาน และอีกราคาหนึ่งในสมุดราคาสำหรับพันธมิตรของคุณได้

นั่นคือความสัมพันธ์สองชุดที่กลายเป็นสิ่งหนึ่ง ต่อกันเป็นทอด จำรายการจัดส่งจากบทที่ 2 ได้ไหม ที่อยู่ระหว่างการจัดส่งกับสินค้า และท่าของสุนัขที่อยู่ระหว่างสุนัขกับท่า? Salesforce ทำแบบเดียวกันเป๊ะตรงนี้ สองครั้ง: Opportunity Product ระหว่างโอกาสทางการขายกับ Price Book Entry และ Price Book Entry ระหว่าง Product กับ Price Book เมื่อคุณอ่านสิ่งนั้นออก คุณก็อ่านโมเดลข้อมูลมาตรฐานส่วนใหญ่ออก

Click to enlarge

นี่คือสายโซ่นั้นในระยะใกล้ พร้อมฟิลด์ที่ยึดมันไว้ด้วยกัน:

Click to enlarge

กฎหนึ่งที่คนมักสะดุด: มีสมุดราคามาตรฐาน (standard price book) และ Price Book Entry ในสมุดราคาเล่มอื่นใดก็ใช้ราคามาตรฐานของสินค้าได้เลย รู้ให้ได้ว่าโอกาสทางการขายใช้สมุดราคาเล่มไหน ก่อนที่คุณจะโหลดสินค้าของมัน

โมเดลการบริการ

ทีนี้อีกฝั่งของบ้าน บัญชีเดิม ผู้ติดต่อเดิม เมื่อมีบางอย่างผิดพลาด ลูกค้าจะเปิดเคส (Case)

เคสมักเกี่ยวกับบางอย่างที่ลูกค้ามี และ Salesforce มีออบเจกต์สำหรับสิ่งนั้น: สินทรัพย์ (Asset) ในโมดูลที่ 5 ผมจะเรียกมันว่าออบเจกต์มาตรฐานที่คนมองข้าม มันคือสิ่งที่ลูกค้ามี ไม่ว่าเขาจะซื้อจากคุณหรือไม่

แล้วลูกค้ามีสิทธิ์ได้รับอะไร? นั่นคือ Entitlement (สิทธิ์การรับบริการ): การสนับสนุนที่บัญชีหนึ่งมีสิทธิ์ได้รับ ซึ่งมักผูกกับสินทรัพย์ สินค้า หรือสัญญาบริการ ใส่ entitlement บนเคส แล้วเคสก็จะรู้ว่าควรได้รับการสนับสนุนระดับไหน

Click to enlarge

ดูเส้นที่วิ่งจากเคสกลับมาหาตัวเอง ทุกเคสมีฟิลด์ Parent Case (เคสแม่) และมันชี้ไปที่อีกเคสหนึ่ง นั่นคือ self-lookup: ความสัมพันธ์จากออบเจกต์ไปหาตัวเอง มันทำให้คนจำนวนมากสับสนในครั้งแรกที่เห็น นี่จึงเป็นสองเหตุผลที่ผมใช้มัน

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

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

เราจะกลับมาเรื่อง self-lookup เมื่อถึงเรื่องความสัมพันธ์ในโมดูลที่ 7

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

ไฟล์และไฟล์แนบ

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

ไฟล์ถูกนับต่างจากเรกคอร์ด Salesforce แบ่งพื้นที่จัดเก็บเป็นสองส่วน: พื้นที่จัดเก็บไฟล์ (file storage) เก็บไฟล์แนบ Files, Salesforce CRM Content, ไฟล์ Chatter และอื่นๆ ทำนองนั้น และพื้นที่จัดเก็บข้อมูล (data storage) เก็บเรกคอร์ดของคุณ พื้นที่จัดเก็บไฟล์เพิ่มขึ้นเร็วเมื่อทุกเรกคอร์ดมีรูปถ่ายหรือภาพสแกน ภาพปริมาณมาก เช่นรูปถ่ายจากแอปภาคสนาม จึงมักควรอยู่นอก Salesforce ทั้งหมด โดย Salesforce เก็บไว้แค่ลิงก์ โมดูลที่ 4 จะกลับมาเรื่องนี้

สองคอลัมน์หรือสองร้อยคอลัมน์

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

นี่คือเคล็ดลับ ทุกครั้งที่ผมเข้าไปใน org ใหม่ หนึ่งในที่แรกที่ผมไปคือ Setup → Storage Usage ผมถึงขั้นขอภาพหน้าจอจากลูกค้าตั้งแต่การคุยครั้งแรก หน้าจอนั้นไม่โกหก มันบอกคุณว่าออบเจกต์ไหนกำลังโต และตัวไหนกลายเป็นช้างไปแล้ว

บัญชีบุคคล: เมื่อลูกค้าเป็นบุคคล

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

นั่นคือบัญชีบุคคล (person account): บัญชีและผู้ติดต่อรวมเป็นเรกคอร์ดเดียว สำหรับบุคคล ฟิลด์ผู้ติดต่อของพวกเขาติดมาด้วย และฟิลด์ที่กำหนดเองจะปรากฏพร้อมคำต่อท้ายของตัวเอง __pc แต่ละรายการนับรวมทั้งพื้นที่จัดเก็บของบัญชีและของผู้ติดต่อ เพราะเบื้องหลังมันเป็นทั้งสองอย่าง

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

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

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

แล้วเมื่อ Salesforce ไม่มีสิ่งที่คุณต้องการล่ะ? คุณก็สร้างมันเอง นั่นคือเรื่องถัดไป

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

• OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): “สมาชิกของรายการสินค้า Product2 ที่เชื่อมกับ Opportunity” และ Price Book Entry เป็นค่าที่จำเป็น
• PricebookEntry (opens in a new tab), Object Reference (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): “ความเชื่อมโยงระหว่าง Pricebook2 กับ Product2” และรายการหนึ่งใช้ราคามาตรฐานได้
• Case (opens in a new tab), Object Reference (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): ParentId “ID ของเคสแม่ในลำดับชั้น ป้ายชื่อคือ Parent Case” เป็น lookup ไปยัง Case
• Entitlement (opens in a new tab), Object Reference (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): “การสนับสนุนลูกค้าที่บัญชีหรือผู้ติดต่อมีสิทธิ์ได้รับ” ซึ่งอาจอิงกับสินทรัพย์ สินค้า หรือสัญญาบริการ
• Data and Storage Resources (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): พื้นที่จัดเก็บไฟล์และพื้นที่จัดเก็บข้อมูลรวมอะไรบ้าง
• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): “เรกคอร์ด Salesforce ส่วนใหญ่ใช้พื้นที่จัดเก็บข้อมูลประมาณ 2 KB” และบัญชีบุคคลประมาณ 4 KB
• Enable Person Accounts (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): “หลังจากเปิดใช้ Person Accounts แล้ว จะปิดไม่ได้”
• Files Connect FAQ (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-09-25)