课程介绍
今天我们来聊聊Salesforce中的数据操作和一些关键考虑因素。数据操作，简单来说，就是在Salesforce中如何添加、修改、删除和查询数据。这些操作是我们在日常工作中经常需要用到的。 首先，我们来看看如何添加数据。在Salesforce中，添加数据通常是通过创建记录来完成的。比如，你想添加一个新的客户信息，你可以在“客户”对象中创建一个新的记录，填写客户的姓名、电话、地址等信息，然后保存。这样，一个新的客户记录就被添加到了系统中。 接下来是修改数据。如果你发现某个客户的信息有误，或者客户的信息发生了变化，你可以找到这条记录，直接修改相应的字段，然后保存。这样，数据就被更新了。 删除数据也很简单。如果你不再需要某条记录，你可以选择删除它。不过，删除操作是不可逆的，所以在删除之前一定要确认好。 最后是查询数据。在Salesforce中，你可以使用“列表视图”或者“报表”来查询数据。比如，你可以创建一个列表视图，筛选出所有“状态”为“活跃”的客户，这样你就可以快速找到这些客户的信息。 在进行这些数据操作时，有几个关键考虑因素需要注意： 1. ，数据完整性，：确保你输入的数据是准确和完整的。错误的数据会导致错误的决策。 2. ，数据安全，：Salesforce提供了强大的数据安全功能，比如字段级安全、记录级安全等。你需要确保只有授权的人才能访问和修改数据。 3. ，数据备份，：虽然Salesforce有自动备份功能，但定期手动备份重要数据也是一个好习惯。 4. ，数据清理，：定期清理不再需要的数据，可以保持系统的整洁和高效。 5. ，数据审计，：Salesforce提供了数据审计功能，可以追踪数据的修改历史。这对于维护数据的透明性和可追溯性非常重要。 总之，数据操作是Salesforce中最基础也是最重要的部分。掌握好这些操作，并注意上述关键考虑因素，可以帮助你更好地管理和利用数据。希望这些内容对你有所帮助！
课程章节
本课程共有 18 个章节
-
1
Before we discuss data operations and key factors that impact your data..
第 15 页让我们一步步来探讨这些问题，确保你能够清晰地理解每一个概念。 首先，，容纳数据的对象模型，。在Salesforce中，数据是通过对象来存储的。你可以把对象想象成数据库中的表，每个对象都有字段，这些字段就像是表中的列。Salesforce提供了标准对象（如Account、Contact）和自定义对象，你可以根据业务需求来创建和管理这些对象。所以，将数据存储在Salesforce中是合理的，只要你的数据模型设计得当。 接下来是，对象的安全和共享模型，。Salesforce提供了非常灵活的权限控制机制。你可以通过配置文件、权限集、角色层次结构等来控制用户对数据的访问权限。比如，全局用户和角色层次结构中的高层用户通常有更高的权限，可以访问更多的数据。你需要确保这些权限设置合理，既能保护敏感数据，又能让用户高效地完成工作。 关于，如何使用数据和对象，，你需要考虑用户的实际操作需求。比如，你是否启用了创建、读取、更新、删除（CRUD）操作？这些操作是否适合用户的日常工作流程？确保用户能够方便地使用数据，同时也要防止误操作。 ，数据丰富，是指在数据加载过程中，是否对数据进行了额外的处理或补充。比如，你可能需要在数据创建时自动填充某些字段，或者进行数据验证以确保数据的完整性。这些流程可以帮助你维护高质量的数据。 ，合规要求，是很多企业必须考虑的问题。如果你有合规要求，比如GDPR或HIPAA，你需要确保Salesforce中的数据管理符合这些法规。你可以通过设置数据保留策略、访问日志等来满足合规要求。 ，收件箱策略，和，存储优化，也是重要的考虑因素。Salesforce中的存储空间是有限的，所以你需要定期清理不必要的数据，比如旧的电子邮件附件或日志文件。你可以设置自动化的策略来管理这些数据，确保存储空间得到有效利用。 最后，，其他企业标准和数据需求，。每个企业都有自己的特定需求，比如数据命名规范、数据同步频率等。你需要确保Salesforce的配置能够满足这些需求，同时也要考虑到未来的扩展性。 希望这些解释能帮助你更好地理解Salesforce中的数据管理。如果你有任何问题，随时问我！
-
2
Force.com Database Architecture
第 16 页今天我们来聊聊Force.com的数据库架构。首先，Force.com使用的是共享数据库架构。这意味着，所有的客户数据都存储在一个共享的数据库中，而不是每个客户都有自己的独立数据库。这样做的好处是，Salesforce可以更高效地管理和维护数据，同时也能降低成本。 在这个共享数据库中，每个客户的数据都是通过一种叫做“数据透视表”的机制来隔离的。你可以把数据透视表想象成一个虚拟的隔离墙，它确保每个客户只能看到和访问自己的数据，而看不到其他客户的数据。这种机制不仅保证了数据的安全性，还确保了数据的隐私性。 总结一下，Force.com的数据库架构是基于共享数据库的，通过数据透视表来实现数据的隔离和安全。这种设计既高效又安全，是Salesforce能够为全球数百万用户提供服务的重要基础。希望这个解释能帮助你更好地理解Force.com的数据库架构。
-
3
Key Data Operations
第 17 页今天我们来聊聊Salesforce中的“关键数据操作”。这个听起来有点高大上的名词，其实就是在Salesforce中处理和管理数据的一些基本操作。你可以把它想象成在整理你的书桌，把重要的文件放在显眼的位置，把不常用的东西收起来，这样你就能更快地找到你需要的东西。 首先，我们来看看“创建数据”。这就像你在书桌上放一本新书。在Salesforce中，你可以创建新的记录，比如一个新的客户信息或者一个新的销售机会。这很简单，你只需要点击“新建”按钮，然后填写必要的信息就可以了。 接下来是“读取数据”。这就像你从书架上拿下一本书来阅读。在Salesforce中，你可以查看已有的记录，了解客户的需求或者销售进度。你可以通过搜索或者浏览列表来找到你需要的信息。 然后是“更新数据”。这就像你在书上做笔记或者更新书签。在Salesforce中，你可以编辑已有的记录，比如更新客户的联系方式或者修改销售机会的状态。这确保你的数据总是最新的。 最后是“删除数据”。这就像你把不再需要的书从书架上拿下来。在Salesforce中，你可以删除不再需要的记录，比如一个已经完成的销售机会。不过，删除操作要小心，因为一旦删除，数据就无法恢复了。 这些就是Salesforce中的关键数据操作。通过这些操作，你可以有效地管理你的数据，确保你的工作流程顺畅无阻。希望这些信息对你有帮助！
-
4
REST/SOAP API
第 18 页今天我们来聊聊Salesforce中的REST和SOAP API。首先，REST和SOAP是两种不同的网络服务协议，它们允许不同的系统之间进行通信和数据交换。在Salesforce中，大多数标准对象都自带开箱即用（OOTB）的API支持，这意味着你可以直接使用这些API来操作数据，而不需要从头开始编写代码。 如果你需要更复杂的功能，你还可以在APEX中开发自定义的REST和SOAP API。APEX是Salesforce的一种编程语言，它允许你创建更复杂的业务逻辑和数据处理流程。 在数据安全方面，Salesforce提供了全面的安全措施。所有的API调用都需要一个有效的会话ID，这确保了只有经过验证的用户才能访问数据。你可以通过SOAP API或使用OAuth协议来进行登录和验证。 对于SOAP API，Salesforce提供了两种主要的服务描述文件（SDF）选项：企业SDF和合作伙伴SDF。企业SDF适用于需要严格遵守合同规定的场景，而合作伙伴SDF则提供了更灵活的合同选项，适用于需要动态调整的合作伙伴关系。 此外，Salesforce还支持相互认证，也就是双向SSL认证，这进一步增强了API调用的安全性。最后，值得一提的是，单个API调用可以处理多达200条记录，这对于批量数据处理非常有用。 希望这些信息能帮助你更好地理解Salesforce中的REST和SOAP API。如果你有任何问题，随时提问！
-
5
Bulk API
第 19 页今天我们来聊聊Salesforce的Bulk API。这个API是基于REST原则设计的，特别适合处理大量的数据。想象一下，如果你有超过10万条记录需要同步到Salesforce，Bulk API就是你的好帮手。 Bulk API的一个特点是可以将数据分成10,000条一批，然后同步发送到Salesforce。这样做的好处是，即使数据量很大，系统也能在后台高效地处理，而你可以通过安装程序来监控整个过程。 虽然Bulk API是“批量”处理数据，但它同时也能处理200条记录。这意味着即使数据量很大，系统也能保持高效运行。对于特别大的数据集，Bulk API还支持PK分块技术，这样可以更好地管理超大数据。 在查询方面，Bulk API通常通过数据加载器或商业RTL工具来访问。这些工具使得操作更加简便，即使你不是技术专家，也能轻松上手。 Salesforce的API是专门为处理大数据量而设计的。举个例子，如果你有10百万条记录，使用Bulk API大约需要3小时30分钟来处理。如果是35百万条记录，可能需要5小时30分钟。而对于95百万条记录，处理时间通常不到10小时。 最后，我们来看一个推杆示例。假设你有一大批数据需要推送到Salesforce，使用Bulk API可以确保这个过程既快速又可靠。你可以设置好参数，然后让系统自动处理，而你只需要监控进度即可。 总的来说，Bulk API是Salesforce中处理大量数据的强大工具，无论是数据同步还是查询，都能提供高效、稳定的支持。希望这个简单的介绍能帮助你更好地理解和使用Bulk API。
-
6
Data Loading
第 20 页今天我们来聊聊数据加载这个话题。数据加载在Salesforce实施过程中是非常关键的一步，它决定了你的系统能否顺利运行。我们可以把数据加载分为两种方式：增量加载和大爆炸加载。 ，增量加载，，顾名思义，就是一点一点地把数据加载到系统中。这种方式适合那些数据量不大，或者你不想一次性把所有数据都导入的情况。它的好处是风险小，容易控制，但可能需要更多的时间。 ，大爆炸加载，，则是把所有数据一次性导入系统。这种方式适合数据量较大，且你希望在短时间内完成数据迁移的情况。它的好处是速度快，但风险也相对较高，因为一旦出现问题，可能会影响整个系统的运行。 接下来，我们来看看数据加载的几个关键步骤： 1. ，实施前活动，：在开始数据加载之前，你需要做一些准备工作。比如，确定数据源、清理数据、映射数据字段等。这一步非常重要，因为它直接影响到数据加载的质量。 2. ，初始负载，：这是数据加载的第一步，通常是把大部分数据导入系统。你可以选择增量加载或大爆炸加载，具体取决于你的需求和数据量。 3. ，赶上并持续同步，：在初始负载之后，你可能还需要把一些新增的数据同步到系统中。这一步确保你的系统数据是最新的。 4. ，用户激活，：数据加载完成后，你需要激活用户，让他们能够使用系统。这一步通常包括设置用户权限、分配角色等。 5. ，验证，：最后一步是验证数据加载是否成功。你需要检查数据是否完整、准确，确保系统能够正常运行。 在整个过程中，你还需要设定一些目标，比如目标1、目标2等。这些目标可以帮助你更好地规划和管理数据加载的过程。 最后，我们来说说，割接，。割接是指从旧系统切换到新系统的过程。在数据加载完成后，你需要进行割接，确保新系统能够顺利接管旧系统的工作。 总结一下，数据加载是一个复杂但非常重要的过程。你需要根据实际情况选择合适的方式，并严格按照步骤进行操作，才能确保数据加载的成功。希望这些内容对你有所帮助！
-
7
Index Rules
第 21 页今天我们来聊聊Salesforce中的索引规则。索引在数据库中非常重要，它可以帮助我们更快地找到数据。但是，使用索引也有一些规则需要遵守，否则它可能不会起到应有的作用。 首先，我们来看自定义索引和标准索引的阈值。自定义索引的阈值是总记录的10%或者333,000条记录，也就是说，如果你的查询结果超过了这个数量，自定义索引可能就不会起作用了。标准索引的阈值稍微高一些，是总记录的20%或者666,000条记录。 接下来，我们来看看“AND”和“OR”这两个逻辑操作符对索引的影响。如果你在查询中使用了“AND”，那么你的查询结果需要低于总记录的20%或者666,000条记录，这样索引才会有效。如果你使用了“OR”，那么你的查询结果需要低于总记录的10%或者所有索引总和333,000条记录。 此外，Salesforce还支持“LIKE”操作符，但使用它时，系统会测试前100,000行的选择性，以确保索引的有效性。 还有一些情况下，索引是不会被使用的。比如，当你在查询中使用了“不等于”（即“！=”）操作符时，索引是不会被使用的。同样，如果你在查询中直接指定了一个值（比如'city='），而没有使用索引字段，索引也不会被使用。 最后，Salesforce提供了一个查询计划工具，这个工具可以帮助你分析你的查询是否会使用索引，以及索引的使用情况如何。这个工具对于优化查询性能非常有帮助。 好了，这就是今天关于Salesforce索引规则的讲解。希望这些信息能帮助你在使用Salesforce时更有效地利用索引，提高查询效率。如果有任何问题，随时提问哦！
-
8
SOQL Best Practices
第 22 页今天我们来聊聊SOQL的最佳实践。SOQL是Salesforce中用来查询数据的语言，就像你问数据库问题一样。但是，问问题也有技巧，我们要尽量问得聪明一点，这样数据库才能更快地回答我们。 首先，，选择性地进行查询，。这意味着我们只查询我们真正需要的数据。比如，如果你只需要客户的名称和邮箱，就不要去查询客户的整个信息。这样可以减少数据库的工作量，查询速度也会更快。 接下来，，指标，。在Salesforce中，我们可以设置一些指标来监控查询的性能。比如，查询返回的记录数、查询执行的时间等。通过这些指标，我们可以知道我们的查询是否高效，是否需要优化。 然后，，瘦桌子，。这里的“瘦桌子”指的是尽量让我们的数据表保持简洁。比如，不要在一个表中存储太多不必要的数据。这样，当我们查询时，数据库需要扫描的数据量就会减少，查询速度自然就快了。 现在，我们来说说，谨慎使用“空”，。在SOQL查询中，如果我们查询的条件是“空”，比如“区域为空”，那么数据库会进行全表扫描。全表扫描就像是你在一本厚厚的书中一页一页地找某个词，非常耗时。所以，我们要尽量避免这种情况。 比如，不要这样写： ```java Account[] acct = [SELECT Name FROM Account WHERE Region__c = :region]; if (acct.size() == 0) status = '未找到'; ``` 这样写的话，如果`region`是空的，数据库就会进行全表扫描。 我们应该这样写： ```java if (region != null) { Account[] acct = [SELECT Name FROM Account WHERE Region__c = :region]; } else { status = '未找到'; } ``` 这样，只有当`region`不为空时，才会执行查询，避免了不必要的全表扫描。 总结一下，SOQL查询时，我们要尽量选择性地查询，监控查询性能，保持数据表简洁，并且谨慎使用“空”条件。这样，我们的查询就会更加高效，数据库也会更开心哦！
-
9
Divisions
第 23 页今天我们来聊聊Salesforce中的数据访问模式，特别是“司”这个概念。首先，想象一下，你有一个非常大的数据库，里面存储了成千上万条记录。如果每个人都试图同时访问这些数据，系统可能会变得非常慢，甚至崩溃。所以，我们需要一种方法来有效地管理和访问这些数据，这就是“司”模式的作用。 “司”模式就像是把一个大数据库分成几个小部分，每个部分只包含特定的数据。这样做的好处是，当用户需要访问数据时，他们只需要访问他们需要的那一小部分，而不是整个数据库。这就像是在一个大图书馆里，每个人只需要去他们感兴趣的书籍区域，而不是整个图书馆。 举个例子，假设你在一家金融服务公司工作，公司有1300万客户和大约500个分支机构。如果每个员工都能访问所有客户的数据，那么系统可能会非常慢。但是，如果我们使用“司”模式，我们可以根据地理位置或责任范围来划分数据。比如，每个分支机构只能访问他们自己的客户数据，这样系统就会更加高效。 需要注意的是，“司”模式主要是用来提高数据访问的性能，而不是用来作为安全措施。它帮助我们分解大对象，优化列表和报告的性能，但并不意味着每个用户只能看到他们应该看到的数据。安全性还需要通过其他方式来实现，比如权限设置和角色控制。 总结一下，“司”模式是一种有效的数据管理策略，它通过分解大数据库来提高访问性能，但它不是安全措施。希望这个解释能帮助你更好地理解这个概念。如果有任何问题，随时问我哦！
-
10
Skinny Tables
第 24 页今天我们来聊聊Salesforce中的一个概念，叫做“瘦桌子”。这个名字听起来有点奇怪，但其实它非常有用。 首先，瘦桌子是Salesforce创建并支持的一种特殊类型的表格。它的主要作用是帮助我们更高效地管理和查询数据。你可以把它想象成一个简化版的表格，它只包含我们真正需要的数据，而不是所有的数据。 那么，瘦桌子是怎么工作的呢？它有几个关键特点： 1. ，评估标准的加入，：瘦桌子会根据我们设定的标准来选择数据。比如，我们可能只想要那些符合特定条件的记录，瘦桌子就会根据这些条件来筛选数据。 2. ，自定义字段，：我们可以根据自己的需求，在瘦桌子中添加自定义字段。这些字段可以帮助我们更好地组织和分析数据。 3. ，与主表保持同步，：瘦桌子中的数据会与主表保持同步。这意味着，当主表中的数据发生变化时，瘦桌子中的数据也会自动更新，确保我们总是看到最新的信息。 4. ，不包括软删除的记录，：瘦桌子不会包含那些被“软删除”的记录。软删除是指那些被标记为删除但实际上还在数据库中的记录。瘦桌子只显示那些真正有效的记录。 5. ，可用于多种对象，：瘦桌子可以用于多种Salesforce对象，比如自定义对象、账户、联系人、机会、线索和案例对象。这意味着无论你是在管理客户信息、销售机会还是支持案例，瘦桌子都能派上用场。 总的来说，瘦桌子是一个非常实用的工具，它帮助我们更高效地管理和查询数据，特别是在处理大量数据时，瘦桌子可以大大提升我们的工作效率。 希望这个解释能帮助你更好地理解瘦桌子的概念。如果你有任何问题，随时问我！
-
11
Skinny Tables - 25
第 25 页大家好，今天我们来聊聊Salesforce中的“瘦桌子”。瘦桌子，顾名思义，就是比较“瘦”的数据表，它不像普通的数据表那样包含大量的数据，而是经过优化，只包含一些关键的数据。这样做有几个好处： 首先，瘦桌子可以减少I/O操作。I/O操作是指数据的输入和输出，减少I/O操作意味着系统可以更快地处理数据，提高效率。 其次，瘦桌子可以更好地利用缓存。缓存是临时存储数据的地方，瘦桌子因为数据量小，可以更容易地被缓存，这样当用户需要数据时，系统可以更快地提供。 再来，瘦桌子减少了接头。这里的“接头”指的是数据表之间的连接，减少接头意味着数据表之间的关系更简单，系统处理起来也更高效。 瘦桌子还支持选择性索引。索引是帮助快速查找数据的工具，选择性索引意味着只对重要的数据进行索引，这样可以进一步提高查询速度。 对于最终用户来说，瘦桌子是不可见的，也就是说，用户在使用Salesforce时，不会直接感觉到瘦桌子的存在，但它的优化效果会让用户感觉到系统运行得更快。 瘦桌子支持报告、列表视图和SOQL查询，这些都是Salesforce中常用的数据展示和查询方式。但是，使用瘦桌子时有一些注意事项： 首先，瘦桌子最多只能包含100列，这意味着你不能在瘦桌子上放太多的数据。 其次，瘦桌子不能拥有来自其他对象的字段，也就是说，瘦桌子上的数据只能来自它自己，不能从其他对象中获取。 还有，瘦桌子不会复制到沙盒环境。沙盒环境是Salesforce用于测试的环境，瘦桌子不会在这里出现，所以如果你在沙盒环境中测试，可能需要注意这一点。 对于报告，字段必须在瘦桌子上，而不是组合。这意味着如果你想要在报告中使用某个字段，这个字段必须直接存在于瘦桌子上，而不是通过组合其他字段得到的。 最后，瘦桌子支持的字段类型包括复选框、日期、日期时间、电子邮件、数字、百分比、电话、选择列表、多选择挑选清单、文本、文本区域、长文本和URL。这些字段类型覆盖了大部分常用的数据类型，可以满足大多数业务需求。 好了，关于瘦桌子的介绍就到这里。希望这些信息能帮助大家更好地理解和使用Salesforce中的瘦桌子。如果有任何问题，欢迎随时提问。谢谢大家！
-
12
PK Chunking
第 26 页今天我们来聊聊Salesforce中的一个非常实用的功能——PK组块（PK Chunking）。这个功能主要是用来优化大数据量查询的，让我们能够更高效地处理大量数据。 首先，PK组块的全称是Primary Key Chunking，也就是主键分块。它的工作原理很简单：当我们查询大量数据时，Salesforce会自动根据记录的主键（也就是SF ID）将数据分成多个小块。每个小块的数据量不会太大，这样查询起来就会更快、更稳定。 举个例子，假设你要查询一个包含100万条记录的对象。如果没有PK组块，Salesforce可能会一次性尝试查询所有数据，这可能会导致超时或者性能问题。但有了PK组块，Salesforce会把这100万条记录分成多个小块，比如每块25万条记录，然后分批查询。这样不仅减少了单次查询的压力，还能避免超时问题。 PK组块还支持批量API，你可以通过设置`Sforce-Wizard-PKChunking: chunkSize=250000`来指定每个块的大小。默认情况下，每个块的大小是25万条记录，但你也可以根据需求调整这个值。 另外，PK组块还支持在块内进行正常的过滤操作。也就是说，你可以在每个小块中使用WHERE子句来进一步筛选数据。这样，即使数据量很大，你也能精确地获取到你想要的结果。 PK组块适用于大多数标准对象和所有自定义对象。也就是说，无论你是查询标准对象（比如Account、Contact）还是自定义对象，都可以使用这个功能。此外，它还支持大多数共享表。如果你需要查询父对象的数据，PK组块也能很好地处理。 总结一下，PK组块是一个非常强大的工具，特别适合处理大数据量的查询。它通过将数据分成小块，分批查询，大大提高了查询的效率和稳定性。无论你是新手还是老手，掌握这个功能都能让你在Salesforce中更加游刃有余。 好了，今天的讲解就到这里，希望你们对PK组块有了更清晰的理解。如果有任何问题，随时问我哦！
-
13
Reports Best Practices
第 27 页今天我们来聊聊Salesforce报告的最佳实践。这些技巧能帮助你更高效地处理数据，让报告更加清晰、有用。 首先，，使用报告过滤器，。这是最基础也是最重要的步骤。通过设置过滤器，你可以快速筛选出你需要的数据，避免在大量信息中迷失方向。比如，你可以过滤出某个时间段内的销售数据，或者某个地区的客户信息。这样，报告就会更加精准，节省你的时间。 接下来，，划分数据，。当你有大量数据时，最好把它们分成小块来处理。比如，你可以按地区、产品类型或时间段来划分数据。这样不仅能让报告更清晰，还能帮助你更容易地发现数据中的趋势和问题。 第三个技巧是，数据去规范化，。听起来有点复杂，但其实很简单。去规范化就是把数据整理得更简洁、更易读。比如，你可以把重复的数据合并，或者把一些不必要的字段去掉。这样，报告看起来会更干净，分析起来也更方便。 最后，，使用数据仓库，。如果你的数据量非常大，或者你需要从多个来源整合数据，那么数据仓库就是一个很好的选择。它可以帮助你集中存储和管理数据，方便你随时调用和分析。这样，你就不用担心数据分散在不同地方，影响报告的准确性了。 总结一下，使用报告过滤器、划分数据、数据去规范化以及使用数据仓库，这些都是Salesforce报告的最佳实践。掌握了这些技巧，你的报告会变得更加高效、清晰，帮助你更好地做出决策。 希望这些内容对你有帮助！如果有任何问题，随时问我哦。
-
14
API Best Practices
第 28 页同学们，今天我们来聊聊Salesforce开发中的API最佳实践。我会用简单易懂的方式来讲解，就像朋友聊天一样。 首先说说Apex触发器和工作流程的选择： - 触发器就像你的私人助理，当数据变化时自动帮你处理复杂逻辑 - 工作流程则像预设好的自动回复，适合简单的字段更新和通知 记住一个原则：能用工作流程解决的，就不要写触发器。就像能用微波炉热饭，就不必开火做饭一样简单。 关于记录大小的小贴士： - 每次处理100-200条记录最合适 - 就像打包行李，装太多会超重，太少又没效率 优化共享的小技巧： - 尽量使用基于角色的共享 - 就像公司里的部门划分，比给每个人单独授权要高效得多 最后说说插入和更新操作： - 插入新记录时，记得检查必填字段 - 更新记录时，先查询再修改，就像改衣服前要先量尺寸 记住这些简单原则，你的Salesforce开发就会像骑自行车一样顺畅自然。有什么不明白的随时问我哦！
-
15
API Best Practices - 29
第 29 页同学们，今天我们来聊聊Salesforce API的最佳实践。我会用最简单的方式给大家讲解，保证你们一听就懂。 首先说说"仅三角洲负载"这个概念。想象一下，你每天都要搬运货物。如果每次都把全部货物搬一遍，那得多累啊？所以聪明的做法是只搬运有变化的货物。在API调用中也是一样，我们只获取那些发生变化的数据，这样能大大减少数据传输量，提高效率。 接下来是"父记录锁定"。这就像是在图书馆借书，如果有人正在借阅某本书，其他人就不能同时借阅。在Salesforce中，当我们更新一个记录时，系统会自动锁定相关的父记录，防止多人同时修改造成冲突。理解这个机制很重要，因为它会影响我们的操作顺序。 第三点是"将大量数据排除在DB之外"。Salesforce数据库就像是一个精装修的房子，空间很宝贵。我们不要把大量文件、图片这些"大件物品"直接存在数据库里，而是应该用外部存储服务。这样既能节省数据库空间，又能提高系统性能。 最后说说"数据库统计信息"。这就像是Salesforce的体检报告，告诉我们数据库的运行状况。系统会自动收集这些数据，帮助我们优化查询性能。比如哪些表最常用，哪些查询最耗时，这些信息对我们优化应用都很有帮助。 记住这些最佳实践，我们在使用Salesforce API时就能事半功倍啦！有什么不明白的地方随时问我。
-
16
Sharing
第 30 页好的同学们，今天我们来聊聊Salesforce中一个非常重要的概念 - 数据访问控制。 想象一下，你们公司有很多部门，每个部门都有自己的数据。财务部的数据不能随便让销售部看到，对吧？Salesforce也是这样管理数据的。 首先，数据访问主要受8个因素控制： 1. 整个企业的默认设置 - 就像公司大门，默认谁能进谁不能进 2. 角色层次 - 就像公司组织架构，上级可以看到下级的数据 3. 共享规则 - 特殊情况下开放某些数据的访问权限 4. 基于标准的共享 - 自动根据条件共享数据 5. 手动共享 - 临时给某人看某个数据 6. 程序化共享 - 用代码控制数据访问 7. 隐性共享 - 系统自动处理的特殊共享情况 8. 其他特殊情况 这些控制方式就像一层层筛子，共同决定谁能看到什么数据。理解这些非常重要，特别是当数据量很大时(LDV)，合理的访问控制能显著提高系统性能。 记住，在Salesforce中，数据安全是第一位的。我们既要确保员工能访问需要的数据，又要保护敏感信息不被泄露。 大家有什么问题吗？我们可以用实际例子来讨论这些概念。
-
17
Sharing Best Practices
第 31 页同学们，今天我们来聊聊Salesforce数据管理中的几个重要原则。就像照顾花园一样，数据管理也需要恰到好处的照料，既不能放任不管，也不能过度保护。 首先，"分享最佳做法"就像园丁之间交流经验。我们要把好的数据管理方法记录下来，比如如何设置字段级安全性，如何设计合理的共享规则。这些经验要像种子一样在团队中传播开来。 说到"避免过度保护数据"，这就像给植物罩上太多防护罩。数据确实需要安全，但如果把每个字段都锁得太死，就像不让植物接触阳光雨露，反而会影响业务运转。我们要在安全和便利之间找到平衡点。 "避免数据集中"这个原则告诉我们，不要把所有的数据都堆在一个地方。就像园丁会把不同植物分开种植一样，我们可以用对象、记录类型等方式合理组织数据，让系统保持整洁有序。 "避免'过度养育'"这个比喻很有趣。就像父母不能替孩子做完所有事情一样，我们也要让用户学会自己处理数据问题。不要设置太多自动化流程来代替人工判断，要给用户留出学习和成长的空间。 最后，"不要将群体筑巢太深"提醒我们，组织结构不要太复杂。就像植物不能种得太密一样，用户组和共享规则的层级最好控制在3-4层以内，否则管理起来会很麻烦。 记住这些原则，我们就能像优秀的园丁一样，培育出健康的数据生态系统。大家有什么问题吗？
-
18
Sharing Best Practices - 32
第 32 页同学们，今天我们来聊聊Salesforce中的几个最佳实践。这些就像是我们日常工作中的小窍门，能让你的工作更轻松高效。 首先说说"简化角色层次结构"。想象一下你们公司的组织架构图，如果层级太多太复杂，是不是看起来很头疼？Salesforce里的角色层次也是一样的道理。我们尽量保持简单明了，一般3-5层就足够了。这样不仅管理起来方便，权限分配也更清晰。 然后是"利用正确的工具完成任务"。这就像我们工具箱里的工具，螺丝刀不能当锤子用，对吧？Salesforce有很多功能模块，我们要根据具体需求选择最合适的。比如处理大量数据就用数据加载器，日常操作就用标准界面，这样效率最高。 最后是"推迟共享计算"。这个稍微专业一点，简单说就是系统在计算记录访问权限时，可以选择在非高峰期进行。就像我们不会在早晚高峰时搬家一样，把计算任务安排在系统不忙的时候，能提高整体性能。 记住这些小技巧，能让你的Salesforce使用体验更顺畅。有什么不明白的随时问我哦！
📋 课程信息
- 所属目录：STA101
- 课程名称：M1 Data Operations and Key Considerations
- 章节数量：18 个