Je joue avec Neo4J, et je me demandais, est-il courant d'avoir une propriété sur des nœuds qui spécifient le type de noeud qu'il s'agit? J'ai essayé de chercher cette pratique et j'ai vu certaines personnes utiliser Un exemple serait un nœud "utilisateur", qui aurait le type: nom dans un but comme celui-ci, mais je me demandais s'il était considéré comme une bonne pratique ou si les indices seraient plus pratiques. Méthode?
utilisateur , de cette façon si l'index était mauvais, je pourrais effectuer une numérisation tout au nœud et rechercher des types de utilisateur .
7 Réponses :
IMHO Vous ne devriez pas avoir à mettre une propriété de type sur le nœud. Au lieu de cela, un moyen courant de faire référence à tous les nœuds d'un "type" spécifique consiste à connecter tous les nœuds de l'utilisateur à un nœud appelé "Utilisateurs" peut-être. De cette façon, commencez au nœud Utilisateurs, vous pouvez trouver très facilement tous les nœuds de l'utilisateur. Le nœud "Utilisateurs" peut être indexé afin que vous puissiez le trouver facilement, ou peut être connecté au nœud de référence.
Le seul problème avec c'est que si vous avez un grand nombre d'utilisateurs, vous commencerez à frapper la pénalité de surnode. Je fais cela maintenant à Neo4django ( Github.com/scholrly/neo4django ) et envisager de passer à un Hyrbid approche index / relation.
J'ai vu ce modèle, je suppose que ma préoccupation était si l'indice / la relation était cassé pour une raison quelconque, le type de nœud est ensuite perdu, mais comme @mattluongo a souligné, nous pouvons déduire de l'utilisation de certains attributs.
Je pense que c'est vraiment à vous. Certaines personnes comme des attributs de type indexés, mais je trouve qu'ils sont surtout utiles lorsque vous avez d'autres attributs indexés pour réduire le nombre de hits d'index (recherche de tous les utilisateurs de plus de 21 ans, par exemple).
Cela dit, comme @Luanne souligne, la plupart d'entre nous essayons de résoudre le problème dans le graphique en premier. Une autre façon de faire cela (et de manière la plus naturelle, à mon avis) consiste à utiliser le type de relation pour déduire un type de noeud pratique, c'est-à-dire «A - (sait) -> B», donc un autre chose qui peut "savoir", et b doit être un autre utilisateur, un sujet ou un autre objet qui peut "être connu".
vrai, cela dépend de votre cas d'utilisation. Si vous ajoutez une propriété de type, puis souhaitez trouver tous les utilisateurs, vous avez des problèmes potentiels car vous devez examiner cette propriété sur chaque nœud pour accéder aux utilisateurs. Dans ce cas, l'indice ferait probablement mieux, mais pas dans les cas où vous devez interroger pour tous les utilisateurs avec des conditions et des relations non disponibles dans l'index (à moins que votre index soit bien sûr la source du «Démarrer»). Si vous avez des graphiques comme le mien, où un type de relation implique deux types de noeuds différents tels que A- (sait) - (b) et A ou B peuvent être un utilisateur ou un client, alors cela ne fonctionne pas.
Donc, votre cas d'utilisation est vraiment important - il est facile de modéliser des graphiques génériques, mais il est important de le "syntoniser" conformément à votre motif d'utilisation.
Pour les API des clients, la modélisation du type d'élément en tant que propriété facilite l'instancier le bon objet de domaine dans votre code côté client afin que j'inclus toujours une propriété de type sur chaque nœud / sommet.
Le nom de Var de type "type" est couramment utilisé pour cela, mais dans certaines langues comme Python, "Type" est un mot réservé, donc j'utilise "Element_Type" dans les ampoules ( http://bulbflow.com/QuickStart/#models ).
Ceci n'est pas nécessaire pour les bords / relations car ils contiennent déjà un type (l'étiquette) - Notez que NEO4J utilise également le mot-clé "Type" au lieu de l'étiquette des relations.
Je dirais que c'est une pratique courante. Par exemple, il s'agit exactement de savoir comment Data Spring NEO4J sait que l'entité type un certain nœud est. Chaque nœud a une propriété «
Les étiquettes ont récemment été ajoutées à Neo4J 2.0 ( http: // docs .neo4j.org / chunked / Milestone / graphdb-neo4j-labels.html ). Ils sont encore en cours de développement pour le moment, mais ils traitent de ce problème exact.
Labels ont été ajoutés à Neo4J 2.0. Ils résolvent ce problème.
Vous pouvez créer des nœuds avec des étiquettes: Vous pouvez correspondre sur les étiquettes: Vous pouvez définir n'importe quel nombre d'étiquettes sur un nœud: Vous pouvez supprimer n'importe quel nombre d'étiquettes sur un nœud: etc ...