不只是資料庫

另有 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)

An apartment building at dusk, every window lit and every apartment furnished differently, above one shared glass lobby with its elevator and mailboxes. — 圖片由 AI 生成

第 1 個模組，共 10 個，屬於 Data Architect 課程第 3 章Salesforce 資料架構。每個模組都可以單獨閱讀。下一篇：看向母艦：標準資料模型

**本模組回答的問題：**Salesforce 和傳統資料庫有什麼不同？

如果你做 Salesforce 管理員已經有一段時間了，你已經知道怎麼建立物件。設定，物件管理員，新建自訂物件。起個名字，加幾個欄位，做一個頁面配置，十分鐘後用戶就能用上了。

但當你點選儲存時，實際上發生了什麼？

如果你有資料庫背景，你多半會想像 Salesforce 去新建了一張表。它沒有。而理解其中的原因，正是你開始從像管理員或開發人員那樣思考，轉向像架構師那樣思考的地方之一。

Salesforce 當然會儲存資料；底層是有資料庫的。但 Salesforce 不是一個上面加了漂亮介面的資料庫。**它是一個後設資料驅動的應用平台，**而這個區別幾乎影響著本課程中的每一個決定。

平台有它的形狀

在第 2 章裡，我們構建模型時完全沒有操心 Salesforce。那是有意的：我們聆聽名詞，構建概念模型，加上屬性、鍵和關係，然後才問 Salesforce 應該如何實現它。現在，我們必須理解我們要在其上實現它的這個東西。

我用一句簡單的話來概括：**平台有它的形狀。**Salesforce 給了我們物件、欄位、關係、安全、自動化、API、事務、報表和搜尋，而它們全都相互連線。當我建立一個物件時，我不只是在建立一個放行的地方。我是在建立一樣東西，它參與安全模型，自動化可以作用於它，API 會公開它，報表可以使用它，其他物件可以與它關聯，而使用者、整合以及越來越多的代理程式都會依賴它。這遠遠不止一張表。

後設資料就是藍圖

想想一棟建築。有建築本身，也有描述它的藍圖：牆在哪裡，門開在哪裡，房間如何連通。Salesforce 也是這樣運作的。物件定義是後設資料。欄位定義是後設資料。關係是後設資料。我們在設定中配置的大部分東西都是後設資料，平台在執行時讀取它們，賦予我們的 org 結構和行為。

Salesforce 把平台的核心描述為既是多租戶的，也是後設資料驅動的：當我們定義一個物件或欄位時，定義是作為後設資料儲存的，而不是為我們的 org 新建一張物理表或一列（Platform Multitenant Architecture (opens in a new tab)，英文）。

講到這裡時，我會掀開引擎蓋給大家看。你每新增一個物件，Salesforce 並不是為你新建一個數據庫。它是在自己的表裡新增一條記錄：一張物件表、一張欄位表、一張資料表，以及用於索引和關係的透視表，全都以一個 org 識別符號為鍵，把你 org 的資料和其他所有人的資料分開。所以新增一個欄位，只是新增一個條目。這就是為什麼你可以在午飯時間、在生產環境裡隨手建立一個欄位。

這也解釋了一件讓人困惑的事。當你寫 SELECT Id, Name, Special__c FROM Account 時，它看起來像是一張表。而在底層，你是在從不同的結構中讀取標準物件和它的自訂欄位，所以平台在做一個你從未寫過的連線。索引是存在的，但它們的工作方式和傳統資料庫索引不同。考試不需要你瞭解內部細節。但你確實需要知道，你在物件管理員裡看到的，並不是物理表的一對一對映，而這種抽象既是平台的力量所在，也是它之所以如此表現的原因。

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。

公寓樓

現在說說那個你總能聽到的詞：多租戶。我把它想像成一棟公寓樓。

你有你的公寓。你的傢俱是你的，你的鑰匙不應該能開啟我的門。但我們共用這棟樓：電、水、電梯、大堂。你的 org 感覺像你自己的環境，有你的資料、你的物件、你的自動化。在底層，Salesforce 把每個 org 描述為一個租戶，隔離每個租戶的資料、後設資料和邏輯，同時共用基礎設施和服務（Platform Multitenant Architecture (opens in a new tab)，英文）。正是這樣，它才能給每個客戶提供一個如此可定製的平台，而不必為每個客戶單獨執行一套技術棧。

但共用一棟樓是有後果的。如果有一戶買了一臺巨大的空調，再同時開著吹風機和烤箱，就會跳閘，整層樓都會斷電。

你不能霸佔電梯

在這棟樓裡再待一會兒。想像有一位住戶宣佈：「我要從八點到中午獨佔電梯，其他人都不能用。」在一棟共用的樓裡這行不通，在 Salesforce 上也一樣行不通。不能允許一個租戶無限制地消耗共用資源，讓所有其他人的平台體驗變差。

這就是控管限制的由來。如果你在 Salesforce 上做過開發，你多半是把它們當作一串要背的數字來認識的。我不希望你這樣看待它們。Salesforce 在事務和 org 層面施加限制，這樣一個租戶的工作負載就不會獨佔共用的計算資源（Architecture Basics (opens in a new tab)，英文）。這才是架構；每一項具體的限制只是它的實現。在課程後面，我們會關心某些具體的限制，因為它們會改變設計。現在，記住這棟樓：你有極大的自由去改造你的公寓，但你不能霸佔電梯。

Salesforce ID 是這層抽象的一部分

每條 Salesforce 記錄都有一個平台能理解的身分，即記錄 ID，它在每一項能力中都通用：介面、API、報表、自動化。

在第 2 章裡我們說過，好的鍵是唯一、不變、無含義、絕不是 PII 的。對 Salesforce 來說，Salesforce ID 符合這些要求。但它和業務鍵不是一回事。你的公司可能還有一個 ERP 客戶編號、一個員工編號，或者一個合作夥伴的訂單號，它們在各個系統之間都有含義。不要把「Salesforce 知道這是哪條記錄」和「企業知道這是哪樣業務事物」混為一談。它們是不同的身分問題，而第二個問題會在整合和主資料中再次出現。

物件不只是儲存

在本章其餘部分之前，我希望你完成這樣一個轉變。物件不只是一個存資料的地方。欄位不只是一列，關係也不只是一個外部索引鍵。我在教學時會用資料庫來做比較，因為這能和人們已有的知識聯絡起來。但如果止步於此，我們就錯過了架構。

我們選擇的物件，決定了隨之而來的能力。欄位類型影響驗證、整合、搜尋、報表，以及其他系統如何讀取資料。關係決定生命週期、所有權、共用和刪除。我們把資料放在哪裡，影響儲存、效能和規模。而且因為這一切都執行在一個共用平台上，一個在一百條記錄下無害的選擇，在一億條記錄下可能表現得截然不同。我們會一個一個地討論這些決定。

**考試之外：AI 改變了什麼。**多年來，好的名稱和描述幫助下一位管理員或開發人員理解我們構建了什麼。現在機器也會讀取這些上下文。一個面對名為 Flag2__c 的欄位的 AI 系統，和一位新來的開發人員有同樣的問題：這個東西是什麼意思？後設資料不再是裝飾，它是機器理解應用的方式的一部分。

架構師在這裡決定什麼

我是在為我實際所在的平台做設計，還是把 Salesforce 當成了一個通用資料庫？
我的設計中哪些部分是業務概念，哪些是 Salesforce 的實現選擇？
我即將建立的結構會附帶哪些平台行為？
哪些限制是共用架構的體現，其中哪些會影響這個設計？
如果這個結構以後很難改變，我是否把它當作一個架構決定來對待？

在第 2 章裡我們說過：不要從設定介面開始設計。現在你又知道了一個原因。點選新建自訂物件不只是給你一張表；它把你架構中的又一塊連線到了一個後設資料驅動的多租戶平台上。但在決定建立什麼物件之前，還有一個更基本的問題：**這些資料到底應該放在這裡嗎？**這是下一個模組的內容。

延伸探索

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：控管限制和執行限制，讓程式碼和事務「不會獨佔共用的計算資源」。