Можно ли генерировать идентификаторы объектов вне CRM?

Мне нужно односторонне синхронизировать внешние данные с CRM на регулярной основе (т.е. каждую ночь).

Это включает в себя создание новых записей, а также обновление существующих.

Это означает, что я должен отслеживать идентификаторы CRM-Entities, созданные моим процессом синхронизации.

Подчеркнутый текстМне уже удалось создать и обновить записи в CRM из строк таблиц базы данных, так что это не проблема.

В настоящее время мои сопоставленные таблицы имеют следующие столбцы

  • id: первичный ключ таблицы, установленный при вставке новой строки
  • new_myentityid: первичный атрибут сопоставленного объекта, установленный после создания записи в процессе синхронизации.
  • new_name и т. д.: значения атрибутов записей

Однако я вижу способ кардинально упростить весь процесс:

Вместо того, чтобы иметь PrimaryKey (id) в базе данных и отслеживать идентификатор CRM (new_myentityid) в отдельном столбце, я мог бы также избавиться от id-столбцов и сделать первичный ключ CRM-ID-Column (new_myentityid) таблицы и установите его при вставке новых записей (newid()), поэтому в основном замените id на new_myentityid с точки зрения базы данных. Затем я мог выполнить массовую рассылку через ExecuteMultipleRequest в сочетании с UpsertRequest.

Таким образом, я бы сохранил столбец в каждой сопоставленной таблице, а также логику для хранения идентификаторов CRM после их создания.

Вопрос

Будет ли это приемлемым или есть что-то, что должно заставить меня избегать этого?


c# dynamics-crm microsoft-dynamics xrm
person nozzleman    schedule 23.01.2017    source источник

Ответы (4)


arrow_upward
6
arrow_downward

Отказ от ответственности: я не знаю наилучшей практики для этого, так что это просто мое личное мнение по этому вопросу, которое несколько раз разрабатывалось для Dynamics.

Я думаю, что использование GUID объекта CRM для вашего первичного ключа — хорошая идея. Это менее сложно и хорошо обрабатывается в SQL. Я предполагаю, что столбец в вашей базе данных uniqueidentifier.

Мой единственный комментарий — не генерировать GUID самостоятельно. Позвольте CRM сгенерировать их для вас, так как она лучше справляется с последовательностью и индексацией всего.

Дополнительные сведения см. в этой записи блога на MSDN. подробно

person Equalsk    schedule 23.01.2017
comment
Да, это тип uniqueidentifier, однако в sql я также могу создать последовательный guid, используя (NEWSEQUENTIALID()), что я делаю и для столбца id, я думаю, crm делает то же самое - person nozzleman; 23.01.2017
comment
Да, но они будут последовательными только с вашей базой данных синхронизации, а не в более широком контексте базы данных CRM, где это важно. Трудно сказать, какое увеличение производительности вы увидите, если оно вообще будет, я полагаю, это зависит от того, говорим ли мы здесь о миллионах строк. Я бы сказал так: доверяете ли вы себе лучше создавать и индексировать GUID, чем Microsoft? ;-) - person Equalsk; 23.01.2017
comment
Я вижу, ты прав с этим. в основном это компромисс между производительностью и опытом разработки при отображении отношений и тому подобного. Тем не менее, ссылка, которую вы предоставили, а также ваше заявление, отвечают на мой вопрос, поэтому я собираюсь принять это. Спасибо! - person nozzleman; 23.01.2017

arrow_upward
3
arrow_downward

Я, вероятно, немного опоздал к этому обсуждению, но просто хотел добавить свою ценность в два пенса.

Нет ничего плохого в указании GUID при создании новой записи в CRM, и это поведение явно поддерживается SDK.

Обычный сценарий реальной жизни — создание записей по сценарию; полезно иметь один и тот же GUID для объекта в средах разработки, тестирования и производства (правда, мы обычно используем GUID, автоматически сгенерированный в среде разработки).

Причина, по которой рекомендуется разрешить CRM генерировать собственный GUID (https://msdn.microsoft.com/en-us/library/gg509027.aspx) заключается в том, что CRM будет генерировать GUID последовательно. Использование newid() создает статистически случайный GUID. Это влияет на производительность SQL-сервера при обслуживании индекса. Этот поток дает некоторое представление: Какова производительность улучшение Sequential Guid по сравнению со стандартным Guid?

Но в основном указание собственного GUID может привести к тому, что базовый оператор SQL INSERT станет более затратным. Операции чтения и обновления должны остаться прежними.

Если вы создаете свои собственные идентификаторы GUID в SQL, вы всегда можете использовать NEWSEQUENTIALID (https://msdn.microsoft.com/en-us/library/ms189786.aspx) для последовательно сгенерированных идентификаторов GUID.

person Malachy    schedule 31.01.2017

arrow_upward
0
arrow_downward

Привет, предыдущие сообщения хорошо это освещают. Просто отметим, что если бы вы генерировали идентификаторы GUID вне CRM, вы могли бы смягчить потенциальное влияние на производительность (INSERTS), просто запустив еженедельный план обслуживания для обновления кластеризованных индексов непосредственно в базе данных SQL, я считаю, что это обеспечит что идентификаторы GUID были упорядочены последовательно. В любом случае, CRM/API всегда будет узким местом, поэтому лучше делать все так, как ожидает платформа, чтобы избежать проблем в дальнейшем.

person Antony    schedule 08.02.2019

arrow_upward
-2
arrow_downward

Почему бы не сохранить в новой таблице?

любит происхождение существует таблица с именем «клиент», и ваши новые данные сохраняются в «customer_update», поле такое же, как исходная таблица.

это поможет вам в будущем. Может быть, вы захотите взглянуть на происхождение данных.

person Du Jianyu    schedule 23.01.2017
comment
Спасибо за ответ, но в этом нет необходимости, потому что у меня есть ведущий источник данных. Я хочу упростить процесс. Изменения из ведущего источника данных должны переопределять данные CRM. Кроме того, это не отвечает на реальный вопрос. - person nozzleman; 23.01.2017