ทุกโครงสร้างคือพันธะ

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

บทที่ 3 ของ Data Architect ส่วนที่ 1: การเป็นสถาปนิกข้อมูล ก่อนหน้า: การสร้างโมเดลข้อมูลเพื่อความหมาย

นี่คือคำถามที่ผมถามในทุกคลาส ถ้ามีคนบอกว่า “ผมทำงานกับ Salesforce” API name ของออบเจกต์สินค้าคืออะไร?

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

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

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

บทนี้เปลี่ยนชิ้นส่วนพื้นฐานของ Salesforce ให้เป็นการตัดสินใจ

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

โครงสร้างทั้งหมดในภาพเดียว

Salesforce ให้ที่เก็บข้อมูลหกแบบแก่คุณ ผมใส่ไว้ในสไลด์เดียว เพราะงานแรกคือการรู้ว่ามันมีอยู่ทั้งหมด:

โครงสร้าง	มีไว้เพื่ออะไร	ข้อควรระวัง
ออบเจกต์มาตรฐาน	โมเดลของ Salesforce เอง: Account, Contact, Opportunity, Case, Asset และอื่นๆ	ใช้ตามจุดประสงค์ของมัน ไม่อย่างนั้นมันจะต่อต้านคุณ
ออบเจกต์ที่กำหนดเอง	ข้อมูลธุรกิจของคุณเอง	สร้างง่าย ปลดระวางยาก
ออบเจกต์ภายนอก	ข้อมูลที่อยู่ในระบบอื่น แต่แสดงใน Salesforce	ทุกการแตะคือการเรียกออกไปภายนอก (callout)
Big object	ปริมาณมหาศาลที่ต้องเก็บแต่แทบไม่ได้เปิด	ไม่มี UI หรือรายงานมาตรฐาน คิวรีผ่านอินเด็กซ์
ไฟล์	เอกสาร รูปถ่าย และเนื้อหาอื่นๆ	พื้นที่จัดเก็บไฟล์เพิ่มขึ้นเร็ว
Attachment	วิธีเก็บไฟล์แบบเก่า	ล้าสมัยแล้ว: ใช้ไฟล์แทน

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

เส้นทางผ่านบทนี้

บทนี้ใหญ่ จึงมาเป็นสิบส่วน แต่ละส่วนอ่านแยกกันได้ ในบทที่ 2 เราตัดสินใจว่าโมเดลควรเป็นอย่างไร ที่นี่เราตัดสินใจว่ามันควรอยู่บน Salesforce อย่างไร

1. แพลตฟอร์มข้อมูล Salesforce: มากกว่าฐานข้อมูล อะไรทำให้ Salesforce แตกต่าง และทำไมแพลตฟอร์มจึงมีรูปร่างของมัน
2. มองไปที่ยานแม่: โมเดลข้อมูลมาตรฐาน โมเดลการขายและโมเดลการบริการที่ Salesforce สร้างไว้แล้ว ไฟล์ พื้นที่จัดเก็บ และบัญชีบุคคล
3. สร้างเอง: ออบเจกต์ที่กำหนดเอง สิ่งที่หน้าจอ New Custom Object ตัดสินใจ ฟิลด์ที่คุณไม่ได้สร้าง และวิธีอ่าน API name ใดก็ได้: มาตรฐาน กำหนดเอง หรือ managed package
4. ข้อมูลนี้อยู่ที่ไหน? บน core อ้างอิง หรือเก็บถาวร ตัดสินก่อนสร้างออบเจกต์ใดๆ
5. เลือกออบเจกต์ให้ถูก บททดสอบความเข้ากันอย่างพอดี สัมภาระที่ออบเจกต์มาตรฐานพกมาด้วย บัญชีบุคคล และสิทธิ์การใช้งานที่กำหนดว่าคนใช้อะไรได้บ้าง
6. ฟิลด์ก็คือสถาปัตยกรรม ไล่ไปทีละประเภทฟิลด์ พฤติกรรมที่ทำให้คนประหลาดใจ และทำไมทุกฟิลด์ต้องมีคำอธิบาย
7. ความสัมพันธ์มีผลตามมา lookup หรือ master-detail ลึกสามระดับและกว้างสองแม่ ออบเจกต์เชื่อมเชิงตรรกะ (logical junction object) และ Junction Object ของ Salesforce (ออบเจกต์ที่กำหนดเองที่มีความสัมพันธ์ master-detail สองชุด) และข้อจำกัดที่กัดเจ็บ
8. ความเป็นเจ้าของและวงจรชีวิต ใครเป็นเจ้าของเรกคอร์ด ตาราง share ที่ความเป็นเจ้าของกลายเป็นการเข้าถึง และจะเกิดอะไรขึ้นกับเรกคอร์ดตลอดชีวิตของมัน
9. รักษาข้อมูลให้สอดคล้องกัน บันไดความสอดคล้อง: ทุกชั้นมีต้นทุน และคุณไม่มีวัน “แก้” ประวัติเพื่อให้ผ่านกฎใหม่
10. ออกแบบโมเดลเชิงกายภาพของ Salesforce ส่วนหนึ่งของ Steve Trucking จากโมเดลเชิงตรรกะสู่ Salesforce สร้างขึ้นทีละขั้น พร้อมเหตุผล

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

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

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

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

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

• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (ภาษาอังกฤษ)
• Standard User Licenses (opens in a new tab), Salesforce Help (ภาษาอังกฤษ)

ถัดไป: ทำความเข้าใจข้อมูลองค์กร