Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Bonnes pratiques Neptune avec l'utilisation de SPARQL
<a name="best-practices-sparql"></a>

Suivez ces bonnes pratiques lorsque vous utilisez le langage de requête SPARQL avec Neptune. Pour plus d'informations sur l'utilisation de SPARQL dans Neptune, consultez [Accès au graphe Neptune avec SPARQL](access-graph-sparql.md).

**Topics**
+ [Interrogation de tous les graphes par défaut](best-practices-sparql-query.md)
+ [Spécification d'un graphe nommé pour le chargement](best-practices-sparql-graph.md)
+ [Choisir entre FILTER, FILTER...IN et VALUES dans vos requêtes](best-practices-sparql-batch.md)

# Interrogation de tous les graphes par défaut
<a name="best-practices-sparql-query"></a>

Amazon Neptune associe chaque triplet à un graphe nommé. Le graphe par défaut est défini comme l'union de tous les graphes nommés. 

Si vous envoyez une requête SPARQL sans spécifier explicitement un graphe via le mot-clé `GRAPH` ou des constructions telles que `FROM NAMED`, Neptune prend toujours en compte tous les triplets dans votre instance de base de données. Par exemple, la requête suivante renvoie tous les triplets à partir d'un point de terminaison Neptune SPARQL : 

```
SELECT * WHERE { ?s ?p ?o }
```

Les triplets qui apparaissent dans plusieurs graphes ne sont renvoyés qu'une seule fois.

Pour plus d'informations sur la spécification du graphe par défaut, consultez la section [RDF Dataset](https://www.w3.org/TR/sparql11-query/#rdfDataset) dans la spécification de langage de requête SPARQL 1.1.

# Spécification d'un graphe nommé pour le chargement
<a name="best-practices-sparql-graph"></a>

Amazon Neptune associe chaque triplet à un graphe nommé. Si vous ne spécifiez pas un graphe nommé lors du chargement, de l'insertion ou de la mise à jour de triplets, Neptune utilise le graphe nommé de secours défini par l'URI, `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`.

Si vous utilisez le chargeur en bloc Neptune, vous pouvez spécifier le graphe nommé pour utiliser tous les triplets (ou quadrilatères avec la quatrième position vide) à l'aide du paramètre `parserConfiguration: namedGraphUri`. Pour plus d'informations sur la syntaxe de la commande `Load` du chargeur Neptune, consultez [Commande de chargeur Neptune](load-api-reference-load.md).

# Choisir entre FILTER, FILTER...IN et VALUES dans vos requêtes
<a name="best-practices-sparql-batch"></a>

Il existe trois façons de base d'injecter des valeurs dans les requêtes SPARQL :   `FILTER`,   `FILTER...IN` et `VALUES`.

Par exemple, imaginons que vous souhaitiez rechercher les amis de plusieurs personnes dans une seule requête. En utilisant `FILTER`, vous pouvez structurer votre requête comme suit :

```
  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. FILTER (?s = ex:person1 || ?s = ex:person2)}
```

Cette opération renvoie tous les triplets du graphe dans lesquels `?s` est lié à `ex:person1` ou `ex:person2` et qui ont un arc sortant intitulé `foaf:knows`.

Vous pouvez également créer une requête en utilisant `FILTER...IN` qui renvoie des résultats équivalents :

```
  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. FILTER (?s IN (ex:person1, ex:person2))}
```

Vous pouvez également créer une requête en utilisant `VALUES` qui, dans ce cas, renvoie également des résultats équivalents :

```
  PREFIX ex: <https://www.example.com/>
  PREFIX foaf : <http://xmlns.com/foaf/0.1/>

  SELECT ?s ?o
  WHERE {?s foaf:knows ?o. VALUES ?s {ex:person1 ex:person2}}
```

Bien que, dans bien des cas, ces requêtes soient équivalentes sémantiquement, il y a certains cas où les deux variantes `FILTER` diffèrent de la variante `VALUES` :
+ Le premier cas est lorsque vous injectez des valeurs en double, telles que l'injection de la même personne deux fois. Dans ce cas, la requête `VALUES` inclut les doublons dans votre résultat. Vous pouvez explicitement éliminer ces doublons en ajoutant un `DISTINCT` à la clause `SELECT`. Toutefois, dans certaines situations, vous souhaiterez peut-être conserver les doublons dans les résultats des requêtes à des fins d’injection des valeurs redondantes.

  Cependant, les versions `FILTER...IN` et `FILTER` extraient la valeur une seule fois lorsque la même valeur apparaît plusieurs fois.
+ Le deuxième cas est lié au fait que `VALUES` génère toujours une correspondance exacte, alors que `FILTER` pourrait appliquer une promotion de type et réaliser des correspondances partielles dans certains cas.

  Par exemple, lorsque vous incluez une valeur littérale comme `"2.0"^^xsd:float` dans votre clause VALUES, une requête `VALUES` établit une correspondance exacte avec cette valeur littérale, y compris la valeur littérale et le type de données.

  En revanche, `FILTER` produit une correspondance partielle pour ces littéraux numériques. Les correspondances peuvent inclure des littéraux avec la même valeur mais des types de données numériques, par exemple `xsd:double`.
**Note**  
Il n'y a aucune différence entre le `VALUES` comportement `FILTER` et lors de l'énumération des littéraux de chaîne ou. URIs

Les différences entre `FILTER` et `VALUES` peuvent affecter l'optimisation et la stratégie d'évaluation de requête qui en résulte. Sauf si votre cas d'utilisation nécessite des correspondances partielles, nous vous recommandons d'utiliser `VALUES` car cela évite d’examiner les cas spéciaux relatifs au transtypage. En conséquence, `VALUES` produit souvent une requête plus efficace qui s'exécute plus rapidement et qui coûte moins cher.