Salesforce 自定义对象：可扩展数据模型的架构指南

九月 20, 2025

背景与应用场景

作为一名 Salesforce 架构师 (Salesforce Architect)，我的核心职责之一是设计一个可扩展、可维护且高效的解决方案蓝图。在这个蓝图中，数据模型是整个 Salesforce 大厦的基石，而 Custom Objects (自定义对象) 则是我们用来构建这座大厦最关键的砖石。

Salesforce 平台提供了一系列强大的 Standard Objects (标准对象)，如 Account (客户)、Contact (联系人)、Opportunity (商机) 等。它们构成了 CRM 的核心功能，满足了通用的业务需求。然而，每个企业的业务流程都是独一無二的。当标准对象无法精确地映射企业的独特数据结构和业务流程时，自定义对象就显得至关重要。例如：

教育行业：一所大学需要管理课程、学生注册和成绩。我们可以创建 “Course__c”（课程）、“Enrollment__c”（注册）和 “Grade__c”（成绩）等自定义对象来构建一个完整的学生信息系统。
医疗保健：一家医院需要跟踪患者的就诊记录和医疗设备。创建 “Patient_Visit__c”（患者就诊）和 “Medical_Device__c”（医疗设备）对象可以精确地捕捉这些关键信息。
项目管理：一个咨询公司需要管理项目、任务和交付物。通过创建 “Project__c”（项目）、“Task__c”（任务）和 “Milestone__c”（里程碑）对象，可以在 Salesforce 内部打造一个轻量级的项目管理工具。

从架构师的视角来看，自定义对象不仅是数据容器，它们是业务逻辑、自动化流程、用户界面和安全模型的载体。一个精心设计的数据模型可以显著提升系统性能、用户体验和未来的可扩展性；反之，一个糟糕的设计则会埋下技术债，导致系统臃肿、报表困难和维护成本高昂。

原理说明

在技术层面，Salesforce 的一个对象本质上对应着底层多租户数据库中的一张表。当我们创建一个自定义对象时，平台会自动处理底层的数据库架构、索引和 API 端点。作为架构师，我们必须超越这种简单的对应关系，从更高维度理解其设计原理。

数据建模与关系设计

数据建模是定义对象及其相互关系的过程。这是架构设计中最关键的一步。错误的关系选择会对数据可见性、记录所有权和功能实现产生深远影响。

Lookup Relationship (查找关系): 这是一种相对松散的父子关系。子记录和父记录在安全和删除方面是独立的。子记录可以独立存在，并且其所有者可以与父记录不同。从架构上讲，当两个对象之间存在“引用”关系，但生命周期不强相关时，应选择查找关系。例如，一个 “Expense_Report__c”（费用报告）对象可以查找到 “Project__c”（项目）对象，但删除一个项目不应该自动删除相关的费用报告。
Master-Detail Relationship (主从关系): 这是一种紧密耦合的父子关系。子记录（Detail）的生命周期和安全性完全由父记录（Master）控制。删除主记录会自动级联删除所有子记录。子记录没有独立的 Owner 字段，它继承主记录的所有权和共享设置。这种关系支持强大的 Roll-Up Summary Fields (汇总字段)，允许在主记录上自动计算子记录的总和、计数、最小值或最大值。架构决策：当子记录的存在完全依赖于父记录时（例如，“发票行项目”必须属于一张“发票”），应使用主从关系。但需要注意的是，一个对象作为子节点的 M-D 关系数量有限制（最多2个），这会影响模型的灵活性。
Many-to-Many Relationship (多对多关系): Salesforce 没有直接的多对多关系类型。我们通过一个称为 Junction Object (连接对象) 的中间自定义对象来实现。连接对象与两个需要建立多对多关系的对象之间分别建立主从关系。例如，为了连接 “Student__c” 和 “Course__c”，我们可以创建一个 “Enrollment__c” 连接对象，它同时是 “Student__c” 和 “Course__c” 的子对象。

可扩展性与治理

在设计自定义对象时，必须考虑到平台的限制和大规模数据量 (Large Data Volumes, LDV) 的影响。

命名约定: 建立并强制执行严格的命名约定至关重要。这包括对象 API 名称 (如 `Project__c`)、字段 API 名称 (如 `Start_Date__c`) 和标签。清晰的命名可以提高代码和配置的可读性，并减少混淆。
描述的重要性: 始终为每个自定义对象和字段填写详细的描述。这将成为未来管理员、开发人员和架构师理解您设计意图的“活文档”。
避免对象泛滥: 在创建新对象之前，首先评估是否可以通过为现有标准或自定义对象添加字段或使用 Record Types (记录类型) 来满足需求。过多的对象会使系统变得复杂，增加维护负担。

示例代码

作为架构师，我们经常需要通过元数据来定义和部署数据模型，而不是完全依赖 UI 手动创建。这确保了环境之间的一致性和可重复性。以下是使用 Metadata API (元数据 API) 定义一个名为 “Project__c” 的自定义对象的 XML 示例。这段代码通常保存在名为 `Project__c.object` 的文件中，并通过 Salesforce DX 或其他部署工具进行部署。

此示例代码直接来源于 Salesforce 官方的《Metadata API Developer Guide》。

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <!-- actionOverrides, fieldSets, etc. would be here -->
    
    <!-- 部署状态，'Deployed' 表示所有用户可见 -->
    <deploymentStatus>Deployed</deploymentStatus>
    
    <!-- 对象描述，解释此对象的用途，对于架构文档至关重要 -->
    <description>Tracks company-wide projects, budgets, and milestones.</description>
    
    <!-- 启用活动、历史跟踪和 Chatter Feed -->
    <enableActivities>true</enableActivities>
    <enableFeeds>true</enableFeeds>
    <enableHistory>true</enableHistory>
    <enableReports>true</enableReports>
    
    <!-- 对象的单数标签 -->
    <label>Project</label>
    
    <!-- 定义记录名称字段的标签和类型。这里使用自动编号 -->
    <nameField>
        <displayFormat>PROJ-{00000}</displayFormat>
        <label>Project Number</label>
        <trackHistory>false</trackHistory>
        <type>AutoNumber</type>
    </nameField>
    
    <!-- 对象的复数标签 -->
    <pluralLabel>Projects</pluralLabel>
    
    <!-- 定义搜索布局 -->
    <searchLayouts/>
    
    <!-- 共享模型，这是架构设计的关键安全决策 -->
    <!-- 'Private' 表示记录默认只有所有者和其上级可见 -->
    <sharingModel>Private</sharingModel>
</CustomObject>

通过这种声明式 XML，我们可以精确控制对象的每一个属性，并将其纳入版本控制系统 (如 Git)，实现基础设施即代码 (Infrastructure as Code) 的最佳实践。

注意事项

在设计和实施自定义对象时，必须仔细考量以下几个方面，以避免未来的性能瓶颈和安全漏洞。

权限与可见性 (Permissions & Visibility)

Organization-Wide Defaults (OWD, 组织范围默认设置): 这是数据安全模型的基石。对于每个自定义对象，你必须设定一个最严格的访问级别（Private, Public Read Only, 或 Public Read/Write）。架构师的首要原则是最小权限原则 (Principle of Least Privilege)，因此通常建议从 `Private` 开始，然后通过其他方式逐步放开权限。
Role Hierarchy (角色层级): 角色层级允许上级用户自动访问其下属拥有的记录。在设计 OWD 时必须考虑角色层级的影响。
Sharing Rules (共享规则): 当角色层级无法满足复杂的共享需求时，可以使用共享规则基于记录所有者或记录条件，将访问权限授予特定的公共组、角色或用户。
Profiles & Permission Sets (简档和权限集): OWD 控制记录级别的可见性，而简档和权限集控制对象级别和字段级别的权限（CRUD - Create, Read, Update, Delete）。最佳实践是使用权限集来授予权限，而不是直接修改简档，这提供了更大的灵活性和可维护性。

API 限制与治理 (API Limits & Governance)

对象数量限制: 不同版本的 Salesforce 对组织中自定义对象的总数有限制。在设计解决方案时，必须了解这些限制，避免触及上限。
字段和关系限制: 每个对象上的自定义字段数量、主从关系数量、查找关系数量等都有明确的限制。过度复杂的对象设计可能会很快耗尽这些资源。
API 名称不可变性: 自定义对象和字段的 API 名称 (`__c` 后缀) 一旦创建就无法更改。因此，在初次创建时遵循命名约定至关重要。错误的命名将成为永久的技术债。

数据倾斜 (Data Skew)

当一个父记录拥有超过 10,000 个子记录时，就会发生数据倾斜。这会导致在更新、删除父记录或更改其所有者时出现性能问题和记录锁定。作为架构师，我们需要预见可能发生数据倾斜的场景（例如，一个“全国总客户”下关联了数百万个订单），并通过设计合理的账户层级或引入归档策略来避免这种情况。

总结与最佳实践

自定义对象是 Salesforce 平台强大灵活性的核心体现，但能力越大，责任越大。作为 Salesforce 架构师，我们必须以长远的眼光来设计数据模型，确保其能够支持企业当前和未来的发展。

以下是构建稳健自定义对象模型的最佳实践：

文档先行: 在创建任何对象之前，先绘制实体关系图 (ERD)，并编写数据字典，明确定义每个对象、字段和关系的业务目的。
优先考虑标准对象: 充分利用标准对象的功能。只有在标准对象确实无法满足需求时，才创建自定义对象。
明智地选择关系类型: 深刻理解查找关系和主从关系在数据生命周期、安全和功能上的差异，并做出最符合业务场景的选择。
设计时考虑报告需求: 与业务分析师和关键用户沟通，了解他们未来的报告需求。这会影响你的字段类型选择和关系设计，例如，主从关系可以轻松创建汇总报告。
安全设计是第一要务: 始终从最严格的 OWD 设置开始，然后通过共享规则和权限集逐步开放访问权限，而不是反其道而行之。
为规模化做好准备: 预估未来的数据量，识别潜在的数据倾斜风险，并从一开始就考虑数据归档和清理策略。
拥抱元数据驱动的开发: 利用 Salesforce DX 和元数据 API 将您的数据模型纳入版本控制，实现自动化、可重复的部署流程。

最终，一个优秀的 Salesforce 架构师不仅知道如何创建自定义对象，更重要的是，他们知道为什么要创建，以及如何设计才能让整个系统在未来几年内保持健康、高效和可扩展。

Salesforce中文网