มากกว่าฐานข้อมูล

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

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

คำถามที่โมดูลนี้ตอบ: อะไรทำให้ Salesforce ต่างจากฐานข้อมูลแบบดั้งเดิม?

ถ้าคุณเป็นผู้ดูแลระบบ Salesforce มาสักพัก คุณรู้วิธีสร้างออบเจกต์อยู่แล้ว Setup, Object Manager, New Custom Object ตั้งชื่อ เพิ่มฟิลด์สองสามฟิลด์ สร้างเลย์เอาต์หน้า แล้วอีกสิบนาทีผู้ใช้ก็ทำงานกับมันได้

แต่จริงๆ แล้วเกิดอะไรขึ้นเมื่อคุณคลิก Save?

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

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

แพลตฟอร์มมีรูปร่างของมัน

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

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

เมทาดาทาคือพิมพ์เขียว

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

Salesforce อธิบายหัวใจของแพลตฟอร์มว่าเป็นทั้ง multitenant และ metadata-driven: เมื่อเรานิยามออบเจกต์หรือฟิลด์ คำนิยามนั้นถูกเก็บเป็นเมทาดาทา ไม่ใช่เป็นตารางหรือคอลัมน์เชิงกายภาพใหม่สำหรับ org ของเรา (Platform Multitenant Architecture (opens in a new tab) ภาษาอังกฤษ)

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

มันยังอธิบายสิ่งที่คนมักสะดุดด้วย เมื่อคุณเขียน SELECT Id, Name, Special__c FROM Account มันดูเหมือนตารางเดียว แต่ข้างใต้ คุณกำลังอ่านออบเจกต์มาตรฐานและฟิลด์ที่กำหนดเองของมันจากโครงสร้างที่ต่างกัน แพลตฟอร์มจึงกำลังทำ join ที่คุณไม่เคยเขียน อินเด็กซ์มีอยู่ แต่ไม่ได้ทำงานแบบอินเด็กซ์ของฐานข้อมูลดั้งเดิม คุณไม่จำเป็นต้องรู้กลไกภายในสำหรับการสอบ แต่คุณต้องรู้ว่าสิ่งที่คุณเห็นใน Object Manager ไม่ใช่ภาพแบบหนึ่งต่อหนึ่งของตารางเชิงกายภาพ และนามธรรมนี้เป็นทั้งพลังของแพลตฟอร์มและเหตุผลที่มันมีพฤติกรรมอย่างที่เป็น

Click to enlarge

มองไปที่ยานแม่

หนึ่งในสิ่งที่ผมบอกในคลาสคือให้มองไปที่ยานแม่ ก่อนจะคิดวิธีซับซ้อนสักอย่างบน Salesforce ให้ดูว่า Salesforce เองทำมันอย่างไร

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

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

เราไม่ได้สร้างอยู่ข้างๆ Salesforce เรากำลังขยายมัน

API ของคุณมาพร้อมกับออบเจกต์

สร้างตารางในฐานข้อมูลดั้งเดิม แล้วคุณก็มีตารางหนึ่งตาราง ถ้าแอปพลิเคชันอื่นต้องทำงานกับมัน ก็ต้องมีคนทำงานเพิ่ม สร้างออบเจกต์บน Salesforce แล้วแพลตฟอร์มเข้าใจมันอยู่แล้วผ่านชั้นแอปพลิเคชันและชั้นการผสานรวม: มันใช้เมทาดาทาเดียวกันในการให้บริการ REST และ SOAP API ดังนั้นเรกคอร์ดของออบเจกต์จึงถูกสร้าง อ่าน อัปเดต และลบผ่าน API เหล่านั้นได้ทันทีที่ออบเจกต์มีอยู่ (Platform Multitenant Architecture (opens in a new tab) ภาษาอังกฤษ)

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

อาคารอพาร์ตเมนต์

ทีนี้มาถึงคำที่คุณได้ยินตลอดเวลา: multitenancy ผมนึกถึงมันเป็นอาคารอพาร์ตเมนต์

คุณมีห้องของคุณ เฟอร์นิเจอร์เป็นของคุณ และกุญแจของคุณไม่ควรเปิดประตูห้องผมได้ แต่เราใช้อาคารร่วมกัน: ไฟฟ้า น้ำ ลิฟต์ ล็อบบี้ org ของคุณให้ความรู้สึกเหมือนสภาพแวดล้อมของคุณเอง มีข้อมูล ออบเจกต์ และระบบอัตโนมัติของคุณ ข้างใต้ Salesforce อธิบายแต่ละ org ว่าเป็น tenant ที่แยกข้อมูล เมทาดาทา และตรรกะของแต่ละ tenant ออกจากกัน ขณะที่โครงสร้างพื้นฐานและบริการใช้ร่วมกัน (Platform Multitenant Architecture (opens in a new tab) ภาษาอังกฤษ) นั่นคือวิธีที่มันให้แพลตฟอร์มที่ปรับแต่งได้สูงแก่ลูกค้าทุกรายโดยไม่ต้องรันระบบแยกให้แต่ละราย

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

คุณยึดลิฟต์ไม่ได้

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

นั่นคือที่มาของ governor limits ถ้าคุณเคยพัฒนาบน Salesforce คุณอาจเคยเจอมันในรูปรายการตัวเลขที่ต้องท่องจำ ผมไม่อยากให้คุณคิดถึงมันแบบนั้น Salesforce ใช้ข้อจำกัดในระดับทรานแซกชันและระดับ org เพื่อไม่ให้ภาระงานของ tenant รายหนึ่งผูกขาดการประมวลผลที่ใช้ร่วมกัน (Architecture Basics (opens in a new tab) ภาษาอังกฤษ) นั่นคือสถาปัตยกรรม แต่ละข้อจำกัดเป็นเพียงการ implement มัน ภายหลังในหลักสูตร เราจะสนใจข้อจำกัดเฉพาะบางข้อเพราะมันเปลี่ยนการออกแบบ สำหรับตอนนี้ ให้นึกถึงอาคาร: คุณมีอิสระมหาศาลในการรีโนเวตห้องของคุณ แต่คุณยึดลิฟต์ไม่ได้

Salesforce ID เป็นส่วนหนึ่งของนามธรรม

ทุกเรกคอร์ดใน Salesforce มีตัวตนที่แพลตฟอร์มเข้าใจ นั่นคือ record ID และมันใช้ได้กับทุกความสามารถ: UI, API, รายงาน, ระบบอัตโนมัติ

ในบทที่ 2 เราบอกว่าคีย์ที่ดีต้องไม่ซ้ำ ไม่เปลี่ยน ไม่มีความหมาย และไม่ใช่ข้อมูลส่วนบุคคล Salesforce ID เข้าเกณฑ์นั้นสำหรับ Salesforce แต่มันไม่ใช่สิ่งเดียวกับคีย์ทางธุรกิจ บริษัทของคุณอาจยังมีหมายเลขลูกค้าใน ERP หมายเลขพนักงาน หรือหมายเลขคำสั่งซื้อของพันธมิตรที่มีความหมายข้ามระบบ อย่าสับสนระหว่าง “Salesforce รู้ว่านี่คือเรกคอร์ดไหน” กับ “องค์กรรู้ว่านี่คือสิ่งทางธุรกิจอะไร” มันเป็นปัญหาตัวตนที่ต่างกัน และข้อที่สองจะกลับมาในเรื่องการผสานรวมและข้อมูลหลัก

ออบเจกต์เป็นมากกว่าที่เก็บข้อมูล

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

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

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

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

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

ในบทที่ 2 เราบอกว่า: อย่าออกแบบจาก Setup ตอนนี้คุณรู้อีกเหตุผลหนึ่งแล้ว การคลิก New Custom Object ไม่ได้แค่ให้ตารางแก่คุณ มันเชื่อมสถาปัตยกรรมของคุณอีกชิ้นเข้ากับแพลตฟอร์มแบบ metadata-driven และ multitenant แต่ก่อนตัดสินใจว่าจะสร้างออบเจกต์อะไร มีคำถามที่พื้นฐานกว่านั้น: ข้อมูลนี้ควรอยู่ที่นี่เลยหรือไม่? นั่นคือเรื่องถัดไป

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

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): คำจำกัดความของออบเจกต์และฟิลด์ถูกเก็บเป็นเมทาดาทา ไม่ใช่ตารางใหม่ ตารางที่ใช้ร่วมกัน (MT_Objects, MT_Fields, MT_Data, MT_Indexes) ใช้ OrgID เป็นคีย์ และเมทาดาทาเดียวกันให้บริการ REST และ SOAP API
• Salesforce Architects, Architecture Basics (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ขีดจำกัด governor และขีดจำกัดการทำงาน เพื่อให้โค้ดและธุรกรรม “ไม่ผูกขาดทรัพยากรการประมวลผลที่ใช้ร่วมกัน”