不只是数据库

另有 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：调控器限制和执行限制，让代码和事务“不会独占共享的计算资源”。