深入解析 Salesforce 对象关系：查找、主从与最佳实践

八月 15, 2025

背景与应用场景

在 Salesforce 平台中，数据模型 (Data Model) 是任何成功应用的基石。而构成数据模型的核心，正是对象关系 (Object Relationships)。对象关系定义了不同的对象 (Objects) 如何相互连接和交互，从而构建出能够反映复杂业务逻辑的结构化数据网络。无论是标准对象还是自定义对象，通过建立关系，我们才能将孤立的数据点转化为有意义的业务信息。

例如，一个“客户 (Account)”对象可能拥有多个“联系人 (Contact)”记录；一个“业务机会 (Opportunity)”会关联多个“产品 (OpportunityLineItem)”；在一个自定义的招聘应用中，一个“职位 (Position)”对象需要与多个“候选人 (Candidate)”对象建立多对多的关联。正确地选择和设计这些关系，不仅影响数据完整性、用户界面和用户体验，更直接决定了系统的安全性、报表能力以及整体性能。作为 Salesforce 技术架构师，深刻理解各种关系类型的特性与差异，是设计可扩展、可维护系统的关键前提。

原理说明

Salesforce 平台提供了多种关系类型来满足不同的业务需求，其中最核心的两种是查找关系 (Lookup Relationship) 和主从关系 (Master-Detail Relationship)。

查找关系 (Lookup Relationship)

查找关系是在两个对象之间建立的一种相对“松散”的连接。它将一个对象（子对象）上的一个字段（查找字段）链接到另一个对象（父对象）上的一条记录。这种关系可以是一对一 (one-to-one) 或一对多 (one-to-many)。

核心特性：

独立性： 子记录和父记录是独立的。它们可以有不同的所有者 (Owner)，并且拥有各自独立的共享和安全设置。
可选性： 默认情况下，子记录上的查找字段可以为空，意味着子记录可以不关联任何父记录而独立存在。当然，你也可以通过字段设置将其设为必填。
删除行为： 删除父记录时，子记录默认不会被删除。子记录上的查找字段值会被清空。管理员可以选择“Don't allow deletion of the lookup record that's part of a lookup relationship”选项来阻止父记录被删除。
限制： 每个对象最多可以有 40 个查找关系。

主从关系 (Master-Detail Relationship)

主从关系是一种“紧密耦合”的父子关系。在这种关系中，子记录（Detail）的存在完全依赖于父记录（Master）。如果父记录被删除，所有关联的子记录也会被级联删除 (cascading delete)。

核心特性：

依赖性： 子记录必须关联到一个父记录，关系字段在页面布局上始终是必填的。
所有权与共享： 子记录没有所有者 (Owner) 字段。它的所有权和共享权限完全由其父记录决定。如果你能看到主记录，你就能看到所有从属记录。
级联删除： 删除主记录会自动删除所有从属记录。恢复主记录时，从属记录也会被一并恢复。
汇总字段： 可以在主对象上创建汇总字段 (Roll-up Summary Field)，用于自动计算从属记录的某些值（如 COUNT, SUM, MIN, MAX）。这是主从关系最强大的功能之一。
限制： 一个对象最多只能有两个主从关系，并且不能作为超过三层的主从关系中的 Detail 对象。

多对多关系 (Many-to-Many Relationship)

Salesforce 本身不直接提供多对多关系类型，但我们可以通过一个称为联结对象 (Junction Object) 的中间对象来实现。联结对象是一个自定义对象，它与另外两个需要建立多对多关系的对象分别建立主从关系。

例如，要实现“招聘岗位”和“候选人”的多对多关系，可以创建一个名为“工作申请 (Job Application)”的联结对象。“工作申请”对象分别与“招聘岗位”和“候选人”建立主从关系。这样，一个岗位可以有多个申请（多个候选人），一个候选人也可以申请多个岗位。

示例代码

在 Apex 或 API 中，我们通常使用 SOQL (Salesforce Object Query Language) 来查询和遍历这些关系。关系查询主要分为两种：子到父 (Child-to-Parent) 和父到子 (Parent-to-Child)。

子到父查询 (Child-to-Parent)

当查询子对象记录时，可以通过关系字段直接访问父对象的字段。对于标准关系，使用对象名（如 `Account`）；对于自定义关系，使用关系名并附加 `__r` 后缀。

// 查询联系人（子）及其所属客户（父）的名称
// 这里的 "Account" 是 Contact 对象上指向 Account 的标准关系字段的名称
List<Contact> contacts = [SELECT Id, FirstName, LastName, Account.Name, Account.Industry 
                           FROM Contact 
                           WHERE Account.Industry = 'Technology'];

// 遍历查询结果
for(Contact c : contacts) {
    // 直接通过 "c.Account.Name" 访问父对象的字段
    System.debug('联系人: ' + c.FirstName + ', 所属客户: ' + c.Account.Name);
}

父到子查询 (Parent-to-Child)

当查询父对象记录时，可以通过内嵌的子查询 (Sub-query) 来获取其所有关联的子记录。子查询中的关系名，对于标准关系通常是对象名的复数形式（如 `Contacts`）；对于自定义关系，是子对象关系字段上定义的“子关系名称 (Child Relationship Name)”并附加 `__r` 后缀。

// 查询所有客户（父）及其关联的所有联系人（子）
// 这里的 "Contacts" 是 Account 对象到 Contact 对象的标准子关系名称
List<Account> accountsWithContacts = [SELECT Id, Name, (SELECT Id, FirstName, LastName FROM Contacts) 
                                      FROM Account 
                                      WHERE Name = 'SFDC Corp'];

// 遍历查询结果
for(Account a : accountsWithContacts) {
    System.debug('客户: ' + a.Name);
    // a.Contacts 是一个 List<Contact> 类型的子记录列表
    List<Contact> childContacts = a.Contacts;
    for(Contact c : childContacts) {
        System.debug('  -- 关联联系人: ' + c.FirstName + ' ' + c.LastName);
    }
}

注意事项

在设计和使用对象关系时，架构师需要考虑以下关键点：

关系转换： 你可以将一个主从关系转换成查找关系，前提是主对象上没有汇总字段。反之，将查找关系转换为主题关系，则需要确保子对象上所有记录的该查找字段都有值。

数据倾斜 (Data Skew)：

所有权与共享： 再次强调，主从关系中的共享模型由主记录驱动，而查找关系中子记录的共享是独立的。这是选择关系类型时最重要的考量之一。
级联删除的影响： 主从关系中的级联删除功能非常强大，但也存在风险。删除一个主记录可能会无意中删除成千上万条重要的子记录。务必确保用户权限和业务流程的严谨性。
API 限制： 每个对象的关系字段数量（查找+主从）总共不能超过 40 个。在复杂的 ERD 设计中需要提前规划。

总结与最佳实践

对象关系是 Salesforce 数据建模的灵魂。理解其细微差别并做出明智的选择，对应用的长期健康至关重要。

总结一下关键选择依据：

当你需要汇总字段，或者子记录的生命周期完全依赖于父记录时，选择 Master-Detail Relationship。
当两个对象之间的关系是可选的，或者它们需要有不同的所有者和共享规则时，选择 Lookup Relationship。
当你需要实现多对多的业务逻辑时，使用一个带有两个主从关系的 Junction Object。

最佳实践建议：

优先选择查找关系： 除非有明确的业务需求（如汇总或级联删除），否则应优先使用更灵活的查找关系。这为未来的扩展和变更提供了更大的空间。
预见数据增长： 在设计阶段就要评估数据量，特别是父子关系中的子记录数量，主动规避数据倾斜风险。
命名规范： 为自定义关系和子关系名称制定清晰的命名规范（例如，`ChildObject_Lookup_to_ParentObject__c`），这有助于提高代码和配置的可读性。
善用架构图： 在开始构建之前，使用 Schema Builder 或其他工具绘制实体关系图 (ERD)，以可视化地审查和验证你的数据模型。

通过遵循这些原则和实践，你可以构建出既能满足当前业务需求，又能适应未来变化的、健壮且高效的 Salesforce 数据模型。

Salesforce中文网