這些資料放在哪裡？
另有 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)
第 4 個模組，共 10 個，屬於 Data Architect 課程第 3 章Salesforce 資料架構。每個模組都可以單獨閱讀。 上一篇：自己動手：自訂物件 · 下一篇：選擇合適的物件
**本模組回答的問題：**在建立物件之前，這些資料實際上應該放在哪裡：放在 Salesforce 的核心之上，在它原本所在的地方引用，還是歸檔？
我問你一個問題。一項新需求落到你桌上。你做的第一件事是什麼？
如果你和我們大多數人一樣，你會開啟設定，建立一個自訂物件。我理解。十分鐘後，你就有了一個標籤頁、一個頁面配置和一個清單檢視。而我會告訴每個班的是：從你建立那個新物件的那一刻起，不管你是否有意，你已經在像架構師一樣思考了。因為你建立的每一個物件都是一份承諾。它佔用儲存。它會碰上限制。它會有一個共用模型，不管你有沒有設計過。每一個接觸它的人都需要一個許可。而一旦人和整合依賴上它，想拿掉它就難了。
所以第一個架構決定不是哪個物件，而是*這些資料應該放在哪裡？*把這個做對，物件類型幾乎會自己選出來。
核心之上與核心之外
Section titled “核心之上與核心之外 ”先說一個我會經常用到的詞：核心（core）。核心就是你的 org 所執行的 Salesforce 平台：模組 1 講的那個後設資料驅動的多租戶平台，模組 2 裡的 Sales 和 Service 物件就放在這裡，你在模組 3 中構建的每一個自訂物件也在這裡。當我說資料在核心之上（on core）時，我的意思是它儲存在你的 org 裡，儲存在 org 的物件中。
並不是所有資料都放在那裡。Data 360 把它的資料儲存在自己的儲存中，在你的 org 的物件之外（它是近核心（near-core）的：在核心之上管理，資料託管在核心之外；詳見第 4 章）。此外，還有你公司執行的、根本不是 Salesforce 的一切：ERP、倉庫、訂單系統、合作夥伴的平台。所有這些都在核心之外（off core）。Salesforce 可以存取它、顯示它、使用它，但你的 org 並不儲存它。
在核心之上，真正儲存你的記錄的物件有兩種：sObject，包括標準物件和自訂物件（__c），以及大物件（__b）。在核心之外，你通過外部物件（__x）和其他整合工具來存取資料。記住模組 3 裡的這些字尾；光看名字，它們就能告訴你一份資料放在哪裡。
我把它想像成一間辦公室。有些東西屬於你的辦公桌，你每天都在用。有些東西你只需要去別人的檔案櫃裡查一下。還有些東西裝進箱子，放到後院的棚子裡。這給了我三個答案。
1. 核心之上：它放在你的辦公桌上
Section titled “1. 核心之上：它放在你的辦公桌上 ”資料每天都在 Salesforce 中被建立、修改和使用：客戶、案例、商機、工作訂單。把它放在 sObject 裡，就像把它放在辦公室的最前面。這正是標準物件和自訂物件的用途，你能得到一切：頁面配置、共用、自動化、報表、搜尋，還有現在構建在資料模型之上的 AI 功能。
不過，你的辦公桌並不是免費的。核心之上的資料要佔用儲存，而且是按 Salesforce 的方式來計算：按記錄計算，而不是按列計算；文件則單獨計入檔案儲存。這兩點我們都在模組 2裡講過。大量的照片和掃描件往往應該放在核心之外，Salesforce 只保留一個連結。
2. 引用：它放在別人的檔案櫃裡
Section titled “2. 引用：它放在別人的檔案櫃裡 ”資料屬於另一個系統（ERP、資料倉儲、訂單平台），而那個系統仍然是真相的來源。使用者需要在 Salesforce 中看到它，也許還要把它與某條記錄關聯，但 Salesforce 不需要擁有自己的副本。你還會聽到有人把它叫作虛擬資料：它以虛擬的方式出現在 Salesforce 中，卻從未儲存在那裡。
這就是通過 Salesforce Connect 使用的外部物件。我常說，它看起來像鴨子，走起來像鴨子，但它不是鴨子。它表現得像一個 sObject：你可以把它放到頁面配置和相關清單上，並通過外部查閱和間接查閱把它與你自己的記錄關聯起來。但資料並不儲存在核心之上。**每次你存取它，它都會發起一次外部呼叫。**開啟一條記錄、載入一個相關清單、執行一份報表，Salesforce 都要去問另一個系統。這意味著延遲，而且你的頁面的可用性取決於它背後的那個系統。
人們會對許可費用有異議，所以像我在課上那樣算一筆賬。Connect 按端點授權，一個端點可以接入很多個物件。再問一問構建和維護替代方案要花多少錢：一個自訂元件，它背後的外部呼叫程式碼，以及出問題時隨叫隨到的開發人員。許可往往更便宜，而且你的管理員不用寫一行程式碼就能配置它。它不適合的地方：使用者整天都在編輯的資料，或者需要大量做報表的資料。
文件也可以被引用。如果一份合同已經放在 SharePoint Online、OneDrive、Google Drive 或 Box 裡，Files Connect 能讓使用者在 Salesforce 中存取它，而無需把它複製進來。
Salesforce Connect 並不是引用資料的唯一方式。有時用的是自訂邏輯：用程式碼即時呼叫另一個系統，並把它的資料呈現在頁面上，不保留任何副本。這給了你完全的控制權，也讓你對外部呼叫、錯誤和日常維護負全部責任。而 Data 360 也能在不復制的情況下做聯邦存取。這個選擇有專門的一章來講（Virtualization, Federation, and Zero-Copy）。在這裡，重點是這個決定本身：引用，而不是複製。
3. 歸檔：它放進後院的棚子裡
Section titled “3. 歸檔：它放進後院的棚子裡 ”歷史、稽核軌跡、舊的交易。你必須保留它們，有時要保留好幾年，但幾乎沒人會開啟。而這正是團隊一拖再拖的事。當有學員告訴我他們有一個 5,000 萬條記錄的物件，問為什麼要歸檔時，我會反問：**如果你今天不歸檔，你還會有歸檔的那一天嗎？**今天 5,000 萬，你正在奔向 1 億、1.5 億、2 億。
棚子有兩個。一個在核心之上：大物件。可以把它們想像成把資料存放在車庫裡。你可以存放海量的記錄，但不能把它們放到頁面配置上，沒有標準的介面或報表，而且要通過大物件的索引來查詢，按精確比對或範圍查詢（Big Objects Best Practices (opens in a new tab)，英文）。安全只有物件和欄位權限，沒有記錄共用，自動化也不會在它們上面執行。我用過幾十次 Salesforce Connect，大物件卻只用過一兩次。它們能用，但很彆扭，為了拿到資料，我也寫過不少變通方案。所以我的建議是：**在建議使用之前先做個原型，**並在選擇它之前就規劃好人們如何找到這些資料。
另一個棚子在核心之外：放在別處的一個資料倉庫或資料庫（Designing for Scale）。這往往是更好的棚子，而且它不一定要藏起來看不見。放在核心之外的歸檔資料仍然可以通過 Tableau 這樣的工具出現在報表裡；當有人需要回頭檢視時，也仍然可以通過 Salesforce Connect 或其他虛擬化方式從 Salesforce 存取到它。
講一個我們從一開始就做對了的專案。一個零售客戶有 1,200 多家門店。他們告訴我：「我們每家門店每天只有一百個預約。沒什麼大不了的。」然後我算了一下：每天一百個，每週六天（一年大約 305 天），1,200 家門店，一年就是 3,600 多萬個預約。接著他們提到，每次到店會產生兩個預約，一個在前臺，一個在後面的店裡：一年 7,300 多萬條記錄。然後他們還想要五年的歷史：還沒算任何增長，就已經超過 3.6 億條記錄。我們還沒上線，我就已經看到這列火車正直奔大數據量那一站而去。所以在收集第一個預約之前，歸檔就已經建好了：較早的預約移到大物件裡，搜尋介面顯示當前的預約，歸檔的預約就列在下方。多年以後，它仍然執行良好。
實際運用：Steve Trucking
Section titled “實際運用：Steve Trucking ”Steve Trucking 是我們貫穿始終的情景：一家家族經營的最後一公里配送公司，它從大型零售商的配送中心提取家電和電子產品，然後送到客戶家裡並安裝。它的四類資料，三個答案：
| 資料 | 放在哪裡 | 原因 |
|---|---|---|
| 今天的配送、配送小組和預約 | 核心之上 | 排程員和配送小組整天都在用它 |
| 零售商的訂單詳情 | 引用（或在核心之上保留一份精簡副本） | 零售商的系統是真相的來源 |
| 三年前的配送歷史 | 歸檔 | 為索賠和趨勢分析而保留；幾乎沒人開啟 |
| 配送照片 | 核心之外，保留連結 | 每天成千上萬張；儲存在 Salesforce 之外，在配送上保留一個連結 |
下面把同樣的內容畫成資料模型。配送（Delivery）放在核心之上，人們整天都在用它。三年之後，它會移到配送歷史（Delivery History）中，這是一個大物件：仍在核心之上，但已經放進了棚子。合作夥伴的訂單以外部物件 __x 的形式出現：Salesforce 把配送與它關聯起來，但資料仍留在零售商的系統裡。而照片完全放在核心之外，由配送上的一個連結指向它們。一個模型，三個歸宿。
每個真實的 org 都有這三類。陷入麻煩的那些，都是把所有東西都放在了核心之上，因為建立物件是預設的那個按鈕。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- **每類資料的歸宿，**在設計任何物件之前：核心之上、引用還是歸檔。
- **真相的來源。**如果另一個系統擁有這些資料，Salesforce 就不應該悄悄地成為第二個主控方。
- **任何核心之外資料的存取路徑。**引用的資料需要一個可用的來源和可接受的延遲；歸檔的資料需要一種讓人找到它的方法。
- **儲存增長。**現在就把賬算清楚（每天的記錄數，乘以增長，乘以保留期限），而不是等到儲存警告來了再算。
**考試之外：AI 抬高了「核心之上」的籌碼。**AI 功能和代理程式在平台能理解的資料上效果最好：放在標準物件和自訂物件中、命名良好、描述清楚的資料。這是一股促使你把更多資料放到核心之上的拉力。對不合適的資料，要抵制它。一個基於 ERP 資料過時副本來落地的代理程式，會給出自信而錯誤的答案。更好的做法往往是引用即時來源，或者只在核心之上保留一小塊描述清楚的資料。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