Каков наилучший способ с точки зрения скорости платформы и возможности поддержки доступа к данным (только для чтения) в Dynamics CRM 4? Я сделал все три, но интересовался мнениями толпы.Как получить доступ к данным в Dynamics CRM?
... и почему?
Мои мысли обычно сосредоточены вокруг вызовов БД на виды, но я знаю, что там есть пуристы.
Учитывая оба требования, я бы сказал, что вы хотите назвать виды. Правильно обработанные SQL-запросы будут летать.
Выполнение API требуется, если вы планируете изменять данные, но это не самый быстрый подход, поскольку он не позволяет осуществлять глубокую загрузку объектов. Например, если вы хотите посмотреть на клиентов и их заказы, вам придется загружать их по отдельности, а затем присоединяться к ним вручную. Где в качестве SQL-запроса уже будут объединены данные.
Никогда не обращайте внимания на то, что поток TDS намного эффективнее, чем SOAP-сообщения, используемые API-интерфейсом &.
UPDATE
Я должен указать в отношении взглядов и базы данных CRM в целом: CRM не оптимизировать индексы таблиц или представлений для пользовательских сущностей (как бы это?). Поэтому, если у вас есть объект loadload, который вы ищете по месту назначения, все время вам нужно добавить индекс для этого свойства. В зависимости от вашего приложения это может иметь огромное значение в производительности.
Я добавлю к комментарию Джейка, говоря, что запрос к таблицам непосредственно вместо представлений (* base & * extensionbase) будет еще быстрее.
Для скорости было бы:
Прямые обновление таблиц:
Я не согласен с Джейком, что все обновления должны пройти через API. Правильный оператор состоит в том, что через API поддерживается только способ обновления. На самом деле существует несколько случаев, когда прямое изменение таблиц является наиболее разумным вариантом:
-Интегральный импорт больших объемов данных, пока система не работает.
-Модификация конкретных полей в больших объемах данных.
Я согласен с тем, что такая прямая модификация должна быть только в крайнем случае, когда производительность API неприемлема. Однако, если вы хотите изменить логическое поле на тысячах записей, простое SQL-обновление для таблицы - отличный вариант.
Относительная скорость Я согласен с XVargas относительно относительной скорости.
Unfiltered Views vs Tables: Я не нашел преимущество в производительности, которое стоило бы хлопот при ручном соединении с базовыми и дополнительными таблицами.
Unfiltered views vs Filtered views: Недавно я работал со сложным запросом, который занимал около 15 минут, используя отфильтрованные виды. После переключения на нефильтрованные представления этот запрос запустил около 10 секунд. Рассматривая соответствующие планы запросов, сырой запрос имел 8 операций, в то время как запрос против фильтрованных представлений имел более 80 операций.
Unfiltered Views vs API: я никогда не сравнивал запрос через API с запросами, но я сравнивал стоимость записи данных через API и вставляя непосредственно через SQL. Импорт миллионов записей через API может занять несколько дней, тогда как одна и та же операция с использованием вставных операторов может занять несколько минут. Я предполагаю, что разница не так велика во время чтения, но, вероятно, она все еще велика.
Будьте осторожны, направляясь непосредственно к столам. Представления обеспечивают безопасность, которая не будет происходить непосредственно с таблицами. Кроме того, делать обновления непосредственно против таблиц - это очень плохая идея. Все обновления должны проходить через API. Sucksville, если у вас много данных, но неспособность сделать это может иметь непредсказуемые результаты. – Jake
Я бы никогда не рекомендовал делать прямые обновления или вставки через таблицы или представления. Однако для широкомасштабных приложений (в сотнях пользователей и миллионах строк) api просто не режет его для запросов. Если вам понадобятся роли безопасности, тогда да, вы должны идти против API или фильтрованных представлений. Оба из них довольно медленны при извлечении большого количества данных. – XVargas