Как получить доступ к данным в Dynamics CRM? - PullRequest
Новая
       26

Как получить доступ к данным в Dynamics CRM?

3 голосов
/ 29 марта 2010

Каков наилучший способ с точки зрения скорости платформы и удобства доступа к данным (только для чтения) в Dynamics CRM 4? Я сделал все три, но интересовался мнением толпы.

  • через API
  • Через веб-сервисы напрямую
  • Через БД вызывает просмотры

... а почему?

Обычно мои мысли сосредоточены на обращениях к БД, но я знаю, что есть пуристы.

Ответы [ 3 ]

2 голосов
/ 29 марта 2010

Учитывая оба требования, я бы сказал, что вы хотите назвать мнения. Правильно созданные SQL-запросы будут летать.

Требуется пройти через API, если вы планируете изменить данные, но это не самый быстрый подход, поскольку он не допускает глубокой загрузки сущностей. Например, если вы хотите посмотреть на клиентов и их заказы, вам нужно будет загрузить их по отдельности, а затем присоединиться к ним вручную. Где в SQL-запросе уже будут объединены данные.

Не берите в голову, что поток TDS намного более эффективен, чем сообщения SOAP, используемые API и веб-сервисами.

UPDATE

Я должен отметить в отношении представлений и базы данных CRM в целом: CRM не оптимизирует индексы таблиц или представлений для пользовательских объектов (как это может быть?). Так что, если у вас есть объект Truckload, который вы ищете по месту назначения все время, вам нужно добавить индекс для этого свойства. В зависимости от вашего приложения это может иметь огромное значение в производительности.

1 голос
/ 29 марта 2010

Я добавлю в комментарий Джейка, сказав, что запросы к таблицам напрямую, а не к представлениям (* base & * extensionbase) будут еще быстрее.

В порядке скорости это будет:

  1. прямой запрос к таблице
  2. просмотр запроса
  3. запрос просмотра с фильтром
  4. вызов API
0 голосов
/ 22 марта 2014

Прямые обновления таблиц:

Я не согласен с Джейком, что все обновления должны проходить через API.Правильным утверждением является то, что использование API - это единственный поддерживаемый способ обновления.Фактически есть несколько случаев, когда прямое изменение таблиц является наиболее разумным вариантом:

  • Однократный импорт больших объемов данных, когда система не работает.

  • Модификация определенных полей для больших объемов данных.

Я согласен, что такого рода прямое изменение должно быть только последним средством, когда производительность APIнеприемлемый.Однако, если вы хотите изменить логическое поле для тысяч записей, сделать прямое обновление SQL для таблицы - отличный вариант.

Относительная скорость

Согласенс XVargas до относительной скорости.

Нефильтрованные представления по сравнению с таблицами. Я не считаю, что преимущество в производительности стоит того, чтобы вручную объединять базовую и дополнительную таблицы.

Нефильтрованные представления и фильтрованные представления.сложный запрос, выполнение которого заняло около 15 минут с использованием отфильтрованных представлений.После переключения на неотфильтрованные представления этот запрос выполнялся примерно через 10 секунд.Если посмотреть на соответствующие планы запросов, в необработанном запросе было 8 операций, а в запросе с отфильтрованными представлениями - более 80 операций.

Нефильтрованные представления и API. Я никогда не сравнивал запросы через API с запросами к представлениям, но сравнивал стоимость записи данных через API и вставки напрямую через SQL.Импорт миллионов записей через API может занять несколько дней, а та же операция с использованием операторов вставки может занять несколько минут.Я предполагаю, что разница не так велика во время чтения, но, вероятно, все еще велика.

...