可以在 CRM 之外生成实体 ID 吗？
Is it OK to generate IDs of entities outside of CRM?
我需要定期（即每晚）将外部数据与 CRM 进行单向同步。
这包括创建新记录以及更新现有记录。
这意味着，我必须跟踪由我的同步过程创建的 CRM 实体的 ID。
强调文本我已经设法从数据库行创建和更新 CRM 中的记录-tables，所以这不是问题。
目前，我映射的 table 有以下列
id: table插入新行时设置的主键new_myentityid：映射实体的主要属性，在同步过程创建记录后设置new_name等：记录属性的值
但是，我看到了一种可以大大简化整个过程的方法：
与其在数据库中使用主键 (id) 并在单独的列中跟踪 CRM ID (new_myentityid)，不如去掉 id-columns 并创建 table 的 CRM-ID-Column (new_myentityid) 主键并在插入新记录时设置它 (newid())，所以基本上替换 id 与 new_myentityid 从数据库的角度来看。然后我可以通过 ExecuteMultipleRequest 结合 UpsertRequest 批量更新插入。
这样，我会在每个映射中保存一列 table 以及在创建它们后存储 CRM ID 的逻辑。
问题
这会被接受吗table 或者有什么可以让我避免这种情况的吗？
为什么不保存在新的 table 中？
likes origin存在一个名为"customer"的table，你的新数据保存在"customer_update"，字段与origintable相同。
它会帮助你 future.maybe 你想看看数据的来源。
免责声明：我不知道这方面的最佳实践，所以这只是我对为 Dynamics 多次开发的问题的个人意见。
我认为使用 CRM 实体 GUID 作为主键是个好主意。它不那么复杂，并且在 SQL 中处理得很好。我假设您数据库中的列是 uniqueidentifier.
我唯一的意见是不要自己生成 GUID。让 CRM 为您生成它们，因为它在保持所有顺序和索引方面做得更好。
这个讨论我可能有点晚了，但只是想增加我的价值。
在 CRM 中创建新记录时指定 GUID 本质上没有错，SDK 明确支持此行为。
一个常见的现实生活场景是通过脚本创建记录；在开发、测试和生产环境中为实体使用相同的 GUID 很有用（诚然，我们通常使用在开发中自动生成的 GUID）。
允许 CRM 生成自己的 GUID 被认为是最佳实践的原因（https://msdn.microsoft.com/en-us/library/gg509027.aspx) is that CRM will generate the GUID sequentially. Using newid() generates a statistically random GUID. This has a performance impact on SQL server around index maintenance. This thread provides some insight: What are the performance improvement of Sequential Guid over standard Guid?
但基本上指定您自己的 GUID 会导致基础 SQL INSERT 语句变得更加昂贵。读取和更新操作应保持不变。
如果您要生成自己的 GUID SQL，您始终可以使用 NEWSEQUENTIALID (https://msdn.microsoft.com/en-us/library/ms189786.aspx) 来顺序生成 GUID。
嗨，以前的帖子对此进行了很好的介绍。请注意，如果您确实在 CRM 之外生成 GUID，您可以通过 运行 每周维护计划直接在 SQL 数据库上直接刷新聚集索引来减轻潜在的性能影响（插入） (s) 我相信这将确保 GUID 是按顺序排列的。无论如何，CRM/API 永远是瓶颈，所以最好按照平台期望的方式做事，以避免以后出现问题。
我需要定期（即每晚）将外部数据与 CRM 进行单向同步。
这包括创建新记录以及更新现有记录。
这意味着，我必须跟踪由我的同步过程创建的 CRM 实体的 ID。
强调文本我已经设法从数据库行创建和更新 CRM 中的记录-tables，所以这不是问题。
目前，我映射的 table 有以下列
id: table插入新行时设置的主键new_myentityid：映射实体的主要属性，在同步过程创建记录后设置new_name等：记录属性的值
但是，我看到了一种可以大大简化整个过程的方法：
与其在数据库中使用主键 (id) 并在单独的列中跟踪 CRM ID (new_myentityid)，不如去掉 id-columns 并创建 table 的 CRM-ID-Column (new_myentityid) 主键并在插入新记录时设置它 (newid())，所以基本上替换 id 与 new_myentityid 从数据库的角度来看。然后我可以通过 ExecuteMultipleRequest 结合 UpsertRequest 批量更新插入。
这样，我会在每个映射中保存一列 table 以及在创建它们后存储 CRM ID 的逻辑。
问题
这会被接受吗table 或者有什么可以让我避免这种情况的吗？
为什么不保存在新的 table 中？
likes origin存在一个名为"customer"的table，你的新数据保存在"customer_update"，字段与origintable相同。
它会帮助你 future.maybe 你想看看数据的来源。
免责声明：我不知道这方面的最佳实践，所以这只是我对为 Dynamics 多次开发的问题的个人意见。
我认为使用 CRM 实体 GUID 作为主键是个好主意。它不那么复杂，并且在 SQL 中处理得很好。我假设您数据库中的列是 uniqueidentifier.
我唯一的意见是不要自己生成 GUID。让 CRM 为您生成它们，因为它在保持所有顺序和索引方面做得更好。
这个讨论我可能有点晚了，但只是想增加我的价值。
在 CRM 中创建新记录时指定 GUID 本质上没有错，SDK 明确支持此行为。
一个常见的现实生活场景是通过脚本创建记录；在开发、测试和生产环境中为实体使用相同的 GUID 很有用（诚然，我们通常使用在开发中自动生成的 GUID）。
允许 CRM 生成自己的 GUID 被认为是最佳实践的原因（https://msdn.microsoft.com/en-us/library/gg509027.aspx) is that CRM will generate the GUID sequentially. Using newid() generates a statistically random GUID. This has a performance impact on SQL server around index maintenance. This thread provides some insight: What are the performance improvement of Sequential Guid over standard Guid?
但基本上指定您自己的 GUID 会导致基础 SQL INSERT 语句变得更加昂贵。读取和更新操作应保持不变。
如果您要生成自己的 GUID SQL，您始终可以使用 NEWSEQUENTIALID (https://msdn.microsoft.com/en-us/library/ms189786.aspx) 来顺序生成 GUID。
嗨，以前的帖子对此进行了很好的介绍。请注意，如果您确实在 CRM 之外生成 GUID，您可以通过 运行 每周维护计划直接在 SQL 数据库上直接刷新聚集索引来减轻潜在的性能影响（插入） (s) 我相信这将确保 GUID 是按顺序排列的。无论如何，CRM/API 永远是瓶颈，所以最好按照平台期望的方式做事，以避免以后出现问题。