Comment accéder aux données dans Dynamics CRM?

Question

Quel est le meilleur moyen en termes de vitesse de la plate-forme et de maintenabilité pour accéder aux données (en lecture seule) sur Dynamics CRM 4? J'ai fait tous les trois, mais intéressé par les opinions de la foule.

• Via l'API
• Via les webservices directement
• Via DB appelle aux vues

... et pourquoi? Mes pensées se concentrent normalement autour des appels DB aux vues mais je sais qu'il y a des puristes là-bas.

Answer 1

Étant donné les deux exigences je dirais que vous voulez appeler les vues. Les requêtes SQL correctement conçues voleront. Passer par l'API est nécessaire si vous envisagez de modifier des données, mais ce n'est pas l'approche la plus rapide, car elle ne permet pas le chargement en profondeur des entités. Par exemple, si vous voulez regarder les clients et leurs commandes, vous devrez les charger individuellement et les joindre manuellement. Où une requête SQL aura déjà les données jointes. Ignorez que le flux TDS est beaucoup plus efficace que les messages SOAP utilisés par les services Web API &.

MISE À JOUR

Je tiens à souligner en ce qui concerne les points de vue et base de données CRM en général: CRM ne pas optimiser les index sur les tables ou vues pour les entités personnalisées (comment pourrait-il?). Donc, si vous avez une entité de chargement que vous recherchez par destination tout le temps, vous devrez ajouter un index pour cette propriété. En fonction de votre application, cela pourrait faire une énorme différence de performance.

Answer 2

Je vais ajouter au commentaire de jake en disant que l'interrogation directe des tables au lieu des vues (* base & * extensionbase) sera encore plus rapide.

Pour la vitesse, il serait:

1. table de requête directe
2. vue requête
3. vue filterd requête
4. appel api

Answer 3

mises à jour de table Direct:

Je ne suis pas d'accord avec Jake que toutes les mises à jour doivent passer par l'API. La déclaration correcte est que le passage par l'API est le seul supporté façon de faire des mises à jour. Il existe en fait plusieurs cas où la modification directe des tables est l'option la plus raisonnable:

-Une fois l'importation de gros volumes de données alors que le système n'est pas en cours d'utilisation.

-Modification de champs spécifiques sur de grands volumes de données.

Je suis d'accord que ce genre de modification directe ne devrait être un dernier recours lorsque la performance de l'API est inacceptable. Cependant, si vous souhaitez modifier un champ booléen sur des milliers d'enregistrements, une mise à jour SQL directe vers la table est une excellente option.

Vitesse relative Je suis d'accord avec XVargas en ce qui concerne la vitesse relative.

Vues Unfiltered vs tableaux: Je n'ai pas trouvé l'avantage de performance pour être en valeur la dispute de se joindre manuellement les tables de base et d'extension.

vues Unfiltered vs vues Filtré: Je travaillais récemment avec une requête complexe qui a pris environ 15 minutes pour exécuter en utilisant les vues filtrées. Après avoir basculé vers les vues non filtrées, cette requête a été exécutée en 10 secondes environ. En regardant les plans de requête respectifs, la requête brute avait 8 opérations alors que la requête sur les vues filtrées avait plus de 80 opérations.

Vues Unfiltered vs API: Je ne l'ai jamais comparé l'interrogation via l'API contre des vues d'interrogation, mais j'ai comparé le coût d'écriture des données via l'API vs insertion directement via SQL. L'importation de millions d'enregistrements via l'API peut prendre plusieurs jours, alors que la même opération utilisant des instructions d'insertion peut prendre plusieurs minutes. Je suppose que la différence n'est pas aussi grande pendant les lectures mais elle est probablement encore grande.