是否可以在 CRM 之外生成实体的 ID？答案

【问题标题】：Is it OK to generate IDs of entities outside of CRM?是否可以在 CRM 之外生成实体的 ID？
【发布时间】：2017-01-23 10:00:54
【问题描述】：

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

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

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

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

目前，我的映射表有以下列

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

不过，我看到了一种大大简化整个过程的方法：

与其在数据库中拥有 PrimaryKey (id) 并在单独的列中跟踪 CRM ID (new_myentityid)，不如去掉 id-columns 并制作 CRM -ID-Column (new_myentityid) 表的主键并在插入新记录时设置它 (newid())，所以从数据库的角度来看，基本上用new_myentityid 替换id。然后我可以通过ExecuteMultipleRequest 和UpsertRequest 进行批量更新。

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

问题

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

【问题讨论】：

标签： c# dynamics-crm microsoft-dynamics xrm

【解决方案1】：

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

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

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

See this blog entry on MSDN for further detail

【讨论】：

是的，它的类型为uniqueidentifier，但是，在 sql 中，我也可以使用 (NEWSEQUENTIALID()) 创建顺序 guid，这也是我为 id 列所做的，我猜 crm 确实如此一样的
是的，但它们只会与您的同步数据库顺序排列，而不是在重要的 CRM 数据库的更大上下文中。很难说你会看到什么样的性能提升，我想这取决于我们是否在这里谈论数百万行。我会这样说：“你相信自己在创建和索引 GUID 方面比 Microsoft 做得更好吗？” ;-)
我明白了，你说得对。基本上它是在映射关系等时性能与开发经验的折衷。但是，您提供的链接以及您的陈述回答了我的问题，所以我将接受这一点。谢谢！

【解决方案2】：

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

在 CRM 中创建新记录时指定 GUID 本身并没有错，SDK 明确支持此行为。

一个常见的现实生活场景是通过脚本创建记录时；在开发、测试和生产环境中为实体使用相同的 GUID 很有用（诚然，我们通常使用开发中自动生成的 GUID）。

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

【讨论】：

【解决方案3】：

嗨，以前的帖子很好地涵盖了这一点。请注意，如果您确实在 CRM 之外生成 GUID，您可以通过运行每周维护计划直接在 SQL 数据库上刷新聚集索引来减轻潜在的性能影响 (INSERTS)，我相信这可以确保GUID 是按顺序排列的。无论如何，CRM/API 总是会成为瓶颈，所以最好按照平台期望的方式做事，以避免以后出现问题。

【讨论】：

【解决方案4】：

为什么不保存在新表中？

likes origin 存在一个名为“customer”的表，您的新数据保存在“customer_update”中，该字段与原始表相同。

它会在未来帮助你。也许你想看看数据的来源。

【讨论】：

感谢您的回复，但没有必要这样做，因为我有一个领先的数据源。我想简化这个过程。来自领先数据源的更改应覆盖 CRM 数据。此外，这并不能回答实际问题。