数据模型是骨架
另有 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)
第 2 个模块，共 7 个，属于 Data Architect 课程的第一章像数据架构师一样思考。每个模块都可以单独阅读。 上一篇：像架构师一样思考 · 下一篇：可逆性测试
**本模块回答的问题：**为什么数据模型比建在它之上的任何东西都重要？又该如何评判一个数据模型？
我教数据架构时，有一句话会一再提起：数据模型是骨架。
数据模型是系统的骨架。其他一切都围绕它构建，正是它把身体的其余部分撑在一起。你看一个人时看不到骨头，但骨头决定了这个人站得多高、怎么活动、能扛多重。
想想我们在 Salesforce 实施中构建的所有东西。我们围绕数据模型构建自动化。我们针对它编写 Apex，编写读取和更新它的 Flow。我们构建集成，把数据送进去、拉出来。我们在它之上做报表和分析，围绕它设计安全。而且越来越多地，我们构建需要理解这些数据并据此行动的 AI 智能体。所有这些都依赖于底层的结构。
这就是为什么尽早把数据模型做对如此重要。骨架以后可以改，但多半会很痛。
从业务开始
Section titled “从业务开始 ”好的数据模型始于一个简单的问题：**业务真正需要表示的是什么？**不是“我们有哪些 Salesforce 对象？”，更不是“我能快速构建什么？”
我们要先理解业务。这个业务里重要的东西是什么？它们之间是什么关系？谁拥有它们？它们如何随时间变化？什么需要被记住，什么在各个业务流程之间共享？只有理解了这些，我们才应该开始把它们转化成对象、字段和关系。
这听起来理所当然，但实际上很容易本末倒置。有人认出某个东西看起来像业务机会、个案或资产，就立刻开始围绕它设计。有时这完全正确。有时我们是在把方钉往圆孔里塞，而一旦围绕这个决定构建了足够多的东西，再把钉子拔出来就会代价高昂。
有个问题我经常听到。一个客户的业务可能有很多个送货地点。每个地点应该是一个客户，还是一个自定义对象？回答之前，先注意你需要先知道什么：地点对这个业务意味着什么，它会经历什么。这就是先给业务建模，再谈对象。（我会在第 3 章给出我的答案。）
支撑。成长。性能。
Section titled “支撑。成长。性能。 ”审视一个数据模型时，我希望它通过三项检验：支撑业务，随业务成长，并且性能过关。
**支撑。**模型必须支撑业务真正想要达成的目标。一个技术上能存下数据的模型，和一个真正把业务表示好的模型，差别很大。如果因为模型不太合适，我不断添加奇怪的字段、特殊的标志、复杂的自动化和例外，我就会开始怀疑问题是否真的出在自动化上。也许是模型错了。好的模型应该让业务更容易理解，而不是更难。
成长。我说的成长，不只是指记录更多。数据量确实重要：一万条记录和一亿条记录带来的问题截然不同。但业务也会在复杂度上成长。它们会增加产品、进入新市场、收购公司、改变流程、增加渠道、连接新系统。它们会发现，原以为是一样东西的，其实是五样不同的东西。一个今天运行得很漂亮的模型，如果没有给明天留出空间，就可能变成陷阱。这就是为什么我更喜欢通过添加来成长的设计，而不是不断修改已有部分的设计。添加新东西，通常比重新定义几十样东西都依赖的东西要容易。
性能。数据不会只是静静地待在那里。我们写入它、查找它、查询它、共享它、对它做报表、集成它，而且越来越多的 AI 系统会在行动前把它作为上下文检索出来。一个模型在图上可能很漂亮，运行起来却很糟糕。所以我们既要为数据如何存储而设计，也要为数据将如何被使用而设计。
而且它必须持续保持性能。它必须在规模下保持性能：用户数增加时，数据量增加时，在真实条件下和高峰时段，在一年中最忙的那一天而不是平均的一天。当意外发生时，它也必须继续保持性能。
支撑。成长。性能。整门课里我们会一再回到这三项检验。
过于扁平、过于复杂，或者干脆错了
Section titled “过于扁平、过于复杂，或者干脆错了 ”我见过数据模型以三种方式出错。
第一种是一开始就选错了东西。我们因为某个标准对象看起来够接近就用了它，然后花好几年不断添加例外，因为它从来就不合适。这就是方钉。
第二种是把模型做得过于扁平。所有东西都放进一个对象里，一开始这显得简单极了。然后业务成长，我们发现其中有些东西有自己的生命周期，可能有多个实例，需要自己的安全设置，或者有自己的关系。突然之间，我们只能用字段 1、字段 2、字段 3，或者越来越复杂的标志和自动化，来表示一对多关系。模型没有给我们留下任何成长的空间。
第三种是相反的错误：我们过度规范化。我们画出一张优雅的图，对象一个接一个，每个概念都分得清清楚楚。技术上很漂亮，用起来很痛苦。用户很难理解它，页面布局和 Lightning 页面上一个接一个的相关列表，会让人感觉深不见底。查询变得更复杂，自动化要跨越更多关系，报表更难做，平台为了回答普通的业务问题也要做更多工作。
那么扁平和规范化，哪个正确？没有公式。你在脑子里装着一个最优模型的样子，并在偏离它时理解其中的权衡。这就是架构的艺术，我们会在模块 4以及下一章学习如何建模时再回到这个话题。现在，先认识到：结构本身就是一个架构决定。
改动骨架要小心
Section titled “改动骨架要小心 ”系统一旦运行起来，我对数据模型的根本性改动就会非常谨慎。
假设一个文本字段已经存在多年，有人说：“我们现在其实不那么用它了，把它改成数字吧。”这听起来只是改个字段。但有什么依赖这个字段？Flow、Apex、报表、集成、数据管道、外部应用、AI 智能体。历史数据又会怎样？只要还有代码或 Flow 引用某个字段，平台本身就不允许你修改它的类型，这就说明了这个改动波及得有多远。
有时正确的做法是不去修改已有的东西。视改动的严重程度而定，我宁愿新建一个，刻意地迁移，再弃用旧结构：
宁可添加，不要修改。宁可弃用，不要突袭。
Salesforce 甚至让你可以在元数据里把这句话说出来：字段的 Field Usage 可以设为 DeprecateCandidate，即“计划弃用，不再使用”。这会给每个阅读该对象的人标出这个字段；它不会隐藏字段，所以让它退役仍然是你要去执行的一个决定。
因为一旦架构的其他部分依赖于某样东西，改变它的含义可能比改变它的名字危险得多。最糟糕的情况是字段名不变而内容变了：下游的一切仍然信任这个名字。
即使是勾选字段上的必填复选框这样简单的事，也可能变成一颗定时炸弹。如果你已经收集了数据，有些记录就不会填写这个字段。然后几天、几周或几个月后，有人更新其中一条记录，保存却因为必填字段而失败，而且谁都没有那个值。把字段设为必填这样简单的改动，可能带来意想不到的、延迟出现的后果。我们会在第 3 章再谈必填，以及一个值什么时候才真正为人所知。
考试之外：AI 也建在骨架之上。让 AI 工具构建一个应用，它会在几分钟内生成对象、字段、Flow、Apex、组件和测试。如果最初的数据模型是错的，我们并没有避免坏决定的后果，而是加速了它们，因为生成的每一层都多了一样依赖那个结构的东西。这就是为什么我希望由人类架构师来评审 AI 生成的数据模型，理解它并为它负责。模块 7 会进一步讨论这一点。
在这门课里，我们会谈到很多技术：对象和关系、大数据量、查询、集成、迁移、事务、安全、Data 360 和 AI。在这一切之下，是数据模型。
如果模型能支撑业务，能随业务成长，并且在我们使用数据的各种方式下性能过关，我们就打下了坚实的基础。如果基础错了，之后的一切都会更难。
**数据模型是骨架。**架构师在设计骨架时应当非常小心。改动现有结构，可能引发连锁反应。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 模型是否能支撑业务、随业务成长，并在数据的各种使用方式下性能过关。
- 一个概念是适合某个标准对象，还是一枚方钉。
- 模型要做得多扁平或多规范化，以及为什么。
- 对骨架的改动应该是一次添加、一次迁移还是一次弃用，而不是原地修改。
- Considerations for Converting the Field Type of a Custom Field (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-10-02；再次查阅 2026-10-12）：哪些类型转换会丢失数据，以及为什么不能修改被 Apex、Flow 或流程引用的字段的类型。
- Data Classification Metadata Fields (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-10-02；再次查阅 2026-10-12）：Field Usage 的取值（Active、DeprecateCandidate、Hidden）以及其他分类字段。