Partage via

Joindre des tables à l’aide de FetchXML

Comme décrit dans Les données de requête à l’aide de FetchXml, démarrez votre requête en sélectionnant une table à l’aide de l’élément d’entité.

Utilisez l’élément link-entity pour décrire les données des tables associées que vous souhaitez retourner avec votre requête. Utilisez les attributs suivants :

Caractéristique Description courte Pour plus d’informations, consultez la référence de l’élément link-entity
name Le nom logique de la table associée.
from Le nom logique de la colonne de la table associée qui correspond à la colonne spécifiée dans l’attribut to.
to Le nom logique de la colonne dans l’élément parent à mettre en correspondance avec la colonne de table associée spécifiée dans l’attribut from.
link-type Type de lien à utiliser. La valeur par défaut est inner, qui limite les résultats aux lignes avec des valeurs correspondantes dans les deux tables.
D’autres valeurs valides sont les suivantes :
- outer
- any
- not any
- all
- not all
- exists
- in
- matchfirstrowusingcrossapply
Découvrez les options de type de lien.
alias Représente le nom de la table associée dans les résultats.
intersect Indique que l’objet link-entity est utilisé pour joindre des tables et ne retourne aucune colonne.

Exemple de base

La requête suivante retourne jusqu’à cinq enregistrements à partir des tables de compte et de contact en fonction de la colonne de recherche PrimaryContactId dans l’enregistrement du compte :

<fetch top='5'>
   <entity name='account'>
      <attribute name='name' />
      <link-entity name='contact'
         from='contactid'
         to='primarycontactid'
         link-type='inner'
         alias='contact'>
         <attribute name='fullname' />
      </link-entity>
   </entity>
</fetch>

Les résultats ressemblent à ceci :

 -----------------------------------------------------------------
 | name                             | contact.fullname           |
 -----------------------------------------------------------------
 | Litware, Inc. (sample)           | Susanna Stubberod (sample) |
 -----------------------------------------------------------------
 | Adventure Works (sample)         | Nancy Anderson (sample)    |
 -----------------------------------------------------------------
 | Fabrikam, Inc. (sample)          | Maria Campbell (sample)    |
 -----------------------------------------------------------------
 | Blue Yonder Airlines (sample)    | Sidney Higa (sample)       |
 -----------------------------------------------------------------
 | City Power & Light (sample)      | Scott Konersmann (sample)  |
 -----------------------------------------------------------------

Limites

Vous pouvez ajouter jusqu’à 15 link-entity éléments à une requête. Chacun link-entity ajoute une jointure à la requête et augmente le temps nécessaire à l’exécution de la requête. Cette limite protège les performances. Si vous ajoutez plus de 15 link-entity éléments à une requête, vous obtenez ce message d’erreur :

Code : 0x8004430D
Nombre : -2147204339
Message : Number of link entities in query exceeded maximum limit.

Éléments enfants

Dans l'élément link-entity, vous pouvez ajouter des éléments enfants tout comme dans l'élément parent afin de :

Relations plusieurs-à-un

L’exemple de base montre une relation plusieurs-à-un où de nombreux enregistrements de compte peuvent faire référence à un enregistrement de contact. Vous définissez ces informations dans la relation plusieurs à un du compte principal, qui a les valeurs suivantes :

Propriété Valeur Commentaire
SchemaName account_primary_contact Nom unique de la relation.
ReferencedEntity contact Table référencée. Le un dans plusieurs-à-un.
ReferencedAttribute contactid Clé primaire de la table référencée.
ReferencingEntity account Table avec une colonne de recherche référençant l’autre table. Le plusieurs dans plusieurs-à-un.
ReferencingAttribute primarycontactid Nom de la colonne de recherche.
RelationshipType OneToManyRelationship Relation un-à-plusieurs lorsqu’elle est vue à partir de la table référencée (une).
Relation plusieurs-à-un lorsqu’elle est vue à partir de la table de référencement (plusieurs).

Récupérer les informations de relation

Si vous utilisez des outils tels que XrmToolBoxFetchXML Builder ou Power Platform ToolBoxFetchXML Studio, vous pouvez voir comment ces outils vous permettent de sélectionner la relation pour définir les valeurs d’attribut appropriéesnamefrom.to

Vous pouvez également utiliser d’autres outils et API pour rechercher les données de relation appropriées pour les valeurs d’attribut name, from et to. Pour savoir comment récupérer ces données, consultez :

Relations 1 à N (un-à-plusieurs)

Les relations de plusieurs à un et d'un à plusieurs sont comme deux côtés de la même pièce. La relation existe entre les tables, de sorte que la façon dont vous l’utilisez dépend de la table de base de votre requête.

Vous pouvez récupérer les mêmes données que l’exemple précédent de la table de contacts à l’aide de la même relation, mais du côté de la table de contacts. Utilisez les données de la même relation un-à-plusieurs account_primary_contact du contact, mais ajustez les valeurs pour la vue différente de la relation.

<fetch top='5'>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         alias='account'>
         <attribute name='name' />
      </link-entity>
   </entity>
</fetch>

Le tableau suivant présente les valeurs d’attribut d’entité de lien dans cet exemple :

Caractéristique Valeur Descriptif
name account Nom logique de la table de référencement
from primarycontactid Le nom de la colonne de recherche dans la table de comptes de référence
to contactid Clé primaire de la table de contacts référencée
alias account Une valeur est recommandée pour l’élément link-entity avec une relation un-à-plusieurs. Si vous ne fournissez pas d’alias, le système génère un alias par défaut. Dans cet exemple, si vous ne fournissez pas d’alias, les données sont retournées avec une colonne nommée account1.name.
link-type Non défini Lorsque vous ne définissez pas de valeur, elle est définie par défaut sur inner

Les résultats incluent les mêmes enregistrements et données que la requête précédente qui utilise la relation plusieurs-à-un. La différence est que l’entité parente est maintenant contact au lieu de account.

 -----------------------------------------------------------------
 | fullname                   | account.name                     |
 -----------------------------------------------------------------
 | Susanna Stubberod (sample) | Litware, Inc. (sample)           |
 -----------------------------------------------------------------
 | Nancy Anderson (sample)    | Adventure Works (sample)         |
 -----------------------------------------------------------------
 | Maria Campbell (sample)    | Fabrikam, Inc. (sample)          |
 -----------------------------------------------------------------
 | Sidney Higa (sample)       | Blue Yonder Airlines (sample)    |
 -----------------------------------------------------------------
 | Scott Konersmann (sample)  | City Power & Light (sample)      |
 -----------------------------------------------------------------

Relations plusieurs à plusieurs

Les relations plusieurs-à-plusieurs s’appuient sur une table d'intersection. Une table d’intersection ne comporte généralement que quatre colonnes, mais seules deux d’entre elles sont importantes. Les deux colonnes importantes correspondent aux colonnes clés primaires des tables participantes.

Par exemple, la table d’intersection TeamMembership prend en charge la relation plusieurs-à-plusieurs teammembership_association entre les tables SystemUser et Team. En utilisant cette relation, les utilisateurs peuvent rejoindre plusieurs équipes, et les équipes peuvent avoir plusieurs utilisateurs. TeamMembership a ces colonnes : systemuserid et teamid.

Pour récupérer des informations sur les utilisateurs et les équipes auxquelles ils appartiennent à l’aide de la teammembership_association relation plusieurs-à-plusieurs, utilisez cette requête fetchXML :

<fetch top='2'>
   <entity name='systemuser'>
      <attribute name='fullname' />
      <link-entity name='teammembership'
         from='systemuserid'
         to='systemuserid'
         intersect='true' >
         <link-entity name='team'
            from='teamid'
            to='teamid'
            link-type='inner'
            alias='team'>
            <attribute name='name' />
         </link-entity>
      </link-entity>
   </entity>
</fetch>

Il existe deux entités de liaison imbriquées.

  • Le premier connecte systemuser à la table d’intersection teammembership, où systemuserid = systemuserid.
  • La deuxième connexion relie teammembership une table d’intersection à team où teamid = teamid.

Les résultats ressemblent à ceci :

 --------------------------------------
 | fullname             | team.name   |
 --------------------------------------
 | FirstName LastName   | org26ed931d |
 --------------------------------------
 | # PpdfCDSClient      | org26ed931d |
 --------------------------------------

Aucune relation

Vous pouvez spécifier les attributs from et to en utilisant des colonnes qui ne font pas partie d'une relation définie.

Par exemple, cette requête recherche des paires d’enregistrements où la colonne Name d’un enregistrement de compte correspond à la colonne FullName d’un enregistrement de contact , qu’elle se référence l’une ou l’autre dans l’une des colonnes de recherche.

<fetch>
   <entity name='account'>
     <attribute name='name' />
     <link-entity name='contact'
       from='fullname'
       to='name'
       link-type='inner'
       alias='contact'>
       <attribute name='fullname' />
     </link-entity>
   </entity>
 </fetch>

Note

Vérifiez que les colonnes que vous spécifiez dans les fromto attributs sont du même type, même si elles ne sont pas impliquées dans une relation. Si vous utilisez des colonnes de différents types, la requête a besoin d’une conversion de type, ce qui peut affecter les performances et peut échouer pour certaines valeurs de colonne.

Vous ne pouvez pas utiliser les types de colonnes suivants dans from et to attributs :

Vous pouvez utiliser ces types de colonnes dans from et to attributs, mais ils peuvent entraîner des performances médiocres :

Rechercher des enregistrements qui ne sont pas dans un ensemble

Vous pouvez utiliser FetchXML pour créer une requête qui retourne des données absentes d'un ensemble à l’aide d’une jointure externe gauche. Une jointure externe gauche renvoie chaque ligne qui satisfait la jointure de la première entrée avec la deuxième entrée. Elle renvoie également toute ligne de la première entrée qui n’a pas de lignes correspondantes dans la seconde entrée. Les lignes non correspondantes de la deuxième entrée sont retournées sous forme de valeurs Null.

Vous pouvez effectuer une jointure externe gauche dans FetchXML à l’aide de l’attribut entityname d’un élément de condition. L’attribut entityname est valide dans les conditions, les filtres et les filtres imbriqués. En savoir plus sur les filtres sur l’entité de lien.

Par exemple, la requête suivante retourne tous les enregistrements de compte sans contacts.

<fetch>
   <entity name='account'>
      <attribute name='name' />
      <order attribute='name' />
      <link-entity name='contact'
         from='parentcustomerid'
         to='accountid'
         link-type='outer'
         alias='contact' />
      <filter type='and'>
         <condition entityname='contact'
            attribute='parentcustomerid'
            operator='null' />
      </filter>
   </entity>
</fetch>

Les types d’entités de liaison suivants ne correspondent pas directement aux types d’opérateurs T-SQL JOIN et utilisent plutôt des sous-requêtes . Ces types fournissent des fonctionnalités plus avancées que vous pouvez utiliser pour améliorer les performances des requêtes et définir des requêtes plus complexes.

Nom Descriptif
exists Une variante de inner qui peut offrir des avantages en termes de performances. Utilise une condition EXISTS dans la clause where. Utilisez-la lorsque plusieurs copies de la ligne parente ne sont pas nécessaires dans les résultats. En savoir plus sur exists et in
in Une variante de inner qui peut offrir des avantages en termes de performances. Utilise une condition IN dans la clause where. Utilisez-la lorsque plusieurs copies de la ligne parente ne sont pas nécessaires dans les résultats. En savoir plus sur exists et in
matchfirstrowusingcrossapply Une variante de inner qui peut offrir des avantages en termes de performances. Utilisez ce type lorsqu’un seul exemple de ligne correspondante de l’entité liée est suffisant et que plusieurs copies de la ligne parente dans les résultats ne sont pas nécessaires. En savoir plus sur matchfirstrowusingcrossapply

Les liens exists et in sont des variantes du type de lien inner. Ils utilisent des conditions différentes (EXISTS et IN respectivement) dans la where clause afin que la requête ne retourne pas plusieurs copies de la ligne parente. Aucun de ces types de liens ne renvoie les valeurs de colonne des lignes d'entité de lien.

exists

Ces exemples FetchXML et SQL montrent les modèles appliqués avec exists.

<fetch>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         link-type='exists'>
         <filter type='and'>
            <condition attribute='statecode'
               operator='eq'
               value='1' />
         </filter>
      </link-entity>
   </entity>
</fetch>

in

Ces exemples FetchXML et SQL montrent les modèles appliqués avec in.

<fetch>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         link-type='in'>
         <filter type='and'>
            <condition attribute='statecode'
               operator='eq'
               value='1' />
         </filter>
      </link-entity>
   </entity>
</fetch>

L'utilisation des types de liens exists ou in peut réduire la taille des résultats de requête intermédiaires ou finaux. Cette réduction est particulièrement utile lorsque de nombreuses lignes liées correspondantes existent pour les mêmes lignes parentes ou lorsque plusieurs entités de liaison sont utilisées avec le même parent. En utilisant les types de liens exists ou in, vous pouvez améliorer les performances de la requête par rapport au type de lien inner, car la requête n’a pas besoin de retourner un produit cartésien contenant toutes les permutations possibles de lignes pour chaque ligne parente provenant d’entités liées différentes.

À l’aide de ces types de liens, Dataverse peut uniquement avoir besoin de trouver la première ligne d’entité liée correspondante pour chaque ligne parente. Cette approche est plus efficace que de rechercher toutes les lignes correspondantes dans l’entité liée dans une inner jointure.

Ce type de lien produit un opérateur CROSS APPLY avec une sous-requête qui utilise top 1 en suivant ce modèle :

<fetch>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         link-type='matchfirstrowusingcrossapply'>
         <attribute name='accountid' />
         <attribute name='name' />
      </link-entity>
   </entity>
</fetch>

Le matchfirstrowusingcrossapply type de lien est équivalent au inner type, sauf qu’il retourne uniquement la ligne parente au plus une fois. La ligne parente est retournée uniquement s’il existe des lignes correspondantes dans l’entité liée, mais, contrairement in aux exists types , elle retourne des valeurs de colonne à partir de l’une des lignes correspondantes de l’entité liée. Utilisez ce type lorsqu’un seul exemple de ligne correspondante de l’entité liée est suffisant et que les résultats n’ont pas besoin de plusieurs copies de la ligne parente.

Lorsque vous utilisez le matchfirstrowusingcrossapply type de lien, les noms des propriétés retournées à l’aide de l’API Web ou des valeurs de collection Keys du SDK pour les colonnes de table associées diffèrent d’autres types de jointures. En règle générale, ces noms suivent le <tablealias>.<logicalname> format. Toutefois, pour le type de matchfirstrowusingcrossapply lien, les valeurs SchemaName sont utilisées sans préfixe d’alias de table.

À l’aide de l’exemple de requête précédent avec n’importe quel autre type de lien, vous pouvez vous attendre à ce que les propriétés ou les clés aient ces noms :

  • fullname
  • contactid
  • account1.accountid
  • account1.name

Mais à l’aide du type de matchfirstrowusingcrossapply lien, les propriétés ou les clés ont les noms suivants :

  • fullname
  • contactid
  • AccountId
  • Name

Étapes suivantes

Découvrez comment trier des lignes.

Lignes de commande

  • Last updated on