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.
Évitez les vérifications redondantes des étiquettes des nœuds en utilisant des noms de relations granulaires
Lors de l'optimisation des performances, l'utilisation d'étiquettes de relation exclusives aux modèles de nœuds permet de supprimer le filtrage des étiquettes sur les nœuds. Prenons un modèle graphique dans lequel la relation likes est uniquement utilisée pour définir une relation entre deux person nœuds. Nous pourrions écrire la requête suivante pour trouver ce modèle :
MATCH (n:person)-[:likes]->(m:person) RETURN n, m
La vérification des person étiquettes sur n et m est redondante, car nous avons défini la relation pour qu'elle n'apparaisse que lorsque les deux sont du même typeperson. Pour optimiser les performances, nous pouvons écrire la requête comme suit :
MATCH (n)-[:likes]->(m) RETURN n, m
Ce modèle peut également s'appliquer lorsque les propriétés sont exclusives à une étiquette de nœud unique. Supposons que seuls person les nœuds possèdent cette propriété. Par conséquentemail, la vérification de la correspondance des étiquettes des nœuds person est redondante. Écrire cette requête comme suit :
MATCH (n:person) WHERE n.email = 'xxx@gmail.com' RETURN n
Est moins efficace que d'écrire cette requête sous la forme suivante :
MATCH (n) WHERE n.email = 'xxx@gmail.com' RETURN n
Vous ne devez adopter ce modèle que lorsque les performances sont importantes et que vous avez effectué des vérifications dans votre processus de modélisation pour vous assurer que ces étiquettes de bord ne sont pas réutilisées pour des modèles impliquant d'autres étiquettes de nœuds. Si vous introduisez ultérieurement une email propriété sur une autre étiquette de nœudcompany, par exemple, les résultats seront différents entre ces deux versions de la requête.
