Microsoft Dynamics CRM Уникальные некластеризованные индексы

Question

Я унаследовал систему Dynamics CRM на работе, выполнив: Версия 1612 (8.2.2.112) (БД 8.2.2.112) локально .

Мы находимся в ситуации, когда кажется, что дублирование происходит с перебоями при отправке формы с последующей повторной отправкой.Мы выпустили документ, объясняющий это поведение, и выразили, как важно сначала проверить, действительно ли некоторые или все транзакции были успешными.Но люди будут людьми, и часто забывают ...

С учетом сказанного, как администратор БД, мой первый инстинкт был создать уникальное ограничение / индекс.Тем не менее, мне не ясно, как лучше всего добиться этого в области динамики.Я не уверен в том, что обнаружение дублирования на уровне приложения является встроенным, и альтернативные ключи не работают для нас, поскольку многие из наших уникальных ограничений требуют включения поля DATE или двух.

Из того, что я могу сказать, добавление индексов в базовые таблицы CRM является поддерживаемым действием DML, но указывает на то, что оно предотвращает обновления.Означает ли это, что мы не можем обновить в будущем?Или просто, что индексы не будут перенесены во время обновления?

Существуют ли лучшие решения, которые мне не хватает, которые обеспечивают согласованность на уровне базы данных и не препятствуют обновлениям?

Answer 1

С помощью локальной CRM вы можете добавлять индексы, и это не указывает, что это не распространяется на кластерные индексы. Я очень рекомендую индексировать базы данных CRM для повышения производительности. По руководству разработчика:

Для локальных развертываний Microsoft Dynamics 365 добавление индексов поддерживается в соответствии с руководящими принципами в развертывании и администрировании Документация по Microsoft Dynamics CRM. Это относится ко всем Microsoft Базы данных Dynamics 365 и Microsoft Dynamics 365 для Outlook локальная база данных.

(я не вижу ничего, что связано с индексами в упомянутой выше документации)

Я не уверен, на какую документацию вы ссылаетесь в отношении обновлений, не поддерживающих эти индексы, у меня никогда не возникало никаких проблем при обновлении организаций CRM с помощью проиндексированных баз данных. Однако при обновлении до версии v9, по-видимому, существуют проблемы, связанные с полнотекстовыми индексами: https://community.dynamics.com/crm/f/117/t/242951

Также, если вы когда-нибудь перейдете в CRM онлайн, весь этот подход больше не будет работать.

Подход, который поддерживается всеми средами CRM, заключается в написании синхронного подключаемого модуля перед операцией, который проверяет ваше условие уникальности и выдает исключение InvalidPluginExecutionException. Это исключение может включать в себя удобное для пользователя сообщение, которое пользователь получит во всплывающем окне стандартной ошибки при попытке создать дубликат. Это гарантированно лучше, чем то, что происходит, когда приложение нарушает ограничение индекса.

Я применяю уникальность контактного адреса электронной почты, используя этот метод, и он работает очень хорошо. У меня настроено правило обнаружения дубликатов, и если пользователь игнорирует дублированное предупреждение и в любом случае создает контакт, он получает сообщение о том, что дублированные адреса электронной почты запрещены.