这些数据放在哪里？
另有 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