可以在CRM之外生成实体的ID吗？

Question

我需要定期（即每晚）与CRM单向同步外部数据。

这包括创建新记录以及更新现有记录。

这意味着，我必须跟踪由同步过程创建的CRM实体的ID。

强调textI我已经设法从数据库表行创建和更新CRM中的记录，因此这不是问题。

目前，我的映射表包含以下列

• id：插入新行时设置的表主键
• new_myentityid：映射实体的主要属性，在同步过程创建记录后设置
• new_name等：记录属性的值

但是，我认为有一种方法可以大大简化整个过程：

我没有在数据库中拥有PrimaryKey（id）并且在单独的列中跟踪CRM ID（new_myentityid），我也可以摆脱id -columns并创建表的CRM-ID-Column（new_myentityid）主键，并在插入新记录（newid()）时设置它，因此基本上用id替换new_myentityid从数据库的角度来看。然后，我可以通过ExecuteMultipleRequest与UpsertRequest一起批量翻转。

这样，我会在每个映射表中保存一列，以及在创建它们之后存储CRM ID的逻辑。

问题

这是可以接受的还是有什么东西可以让我避免这种情况？

Answer 1

免责声明：我不知道这方面的最佳做法，所以这只是我个人对于为Dynamics多次开发的问题提出的意见。

我认为使用CRM实体GUID作为主键是一个好主意。它不那么复杂，在SQL中处理得很好。我假设您的数据库中的列是uniqueidentifier。

我唯一的评论是不自己生成GUID。让CRM为您生成它们，因为它可以更好地保持所有顺序和索引。

See this blog entry on MSDN for further detail

Answer 2

我可能有点迟到这个讨论，但只是想增加我的价值。

在CRM中创建新记录时指定GUID没有任何内在错误，SDK会明确支持此行为。

一种常见的现实生活场景是通过脚本创建记录;在开发，测试和生产环境中为实体提供相同的GUID很有用（不可否认，我们通常使用在Dev中自动生成的GUID）。

允许CRM生成自己的GUID（https://msdn.microsoft.com/en-us/library/gg509027.aspx）被认为是最佳做法的原因是CRM将按顺序生成GUID。使用newid（）生成统计随机GUID。这对SQL服务器的索引维护有性能影响。该主题提供了一些见解：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。

Answer 3

您以前的帖子对此进行了很好的介绍。只是要注意，如果确实要在CRM之外生成GUID，则只需运行每周维护计划以直接在SQL数据库上刷新聚簇索引，就可以减轻潜在的性能影响（INSERTS），我相信这可以确保GUID是按顺序排序的。无论如何，CRM / API始终是瓶颈，因此最好以平台希望避免以后发生问题的方式来做事。

Answer 4

为什么不保存在新表中？

喜欢o​​rigin存在一个名为＆＃34; customer＆＃34;的表，并且您的新数据保存在＆＃34; customer_update＆＃34;中，该字段与原始表相同。

它将来会帮助你。可能你想看看数据的来源。