gérer un "arbre à branches" de nodes

[frednotet]

Bonjour,

Je suis en train de développer un projet qui se base sur un positionnement d'éléments les uns par rapport aux autres.

Graphiquement, cela donne ceci : http://pbrd.co/1vzIkNr

Je suis malheureusement bloqué par le tri des branches les unes par rapport aux autres. J'arrive donc à obtenir l'arbre des éléments (relations :INSIDE) mais je n'arrive pas à trier selon les relations :AFTER; surtout que je lis dans la documentation que je ne peux utiliser ORDER BY sur une relationship (http://docs.neo4j.org/chunked/stable/query-order.html)

Je suis donc en train de me demander si je n'ai pas intérêt à stocker une propriété supplémentaire (par exemple numérique, qui me permettra de stocker cet ordre) comme je le faisais auparavant sous MySQL; ou - et cela me plairait bien - de pouvoir d'une façon ou d'une autre récupérer cet arbre hiérarchique et ordonné d'une "simple" commande cypher...

Bref, je suis un peu paumé dans mes tests et réflexions et je souhaiterais avoir votre aide/avis sur la question...

Merci ;)

[Philippe Baumard]

Bonjour,

J'ai vu avec l'usage qu'il faut être très malin avec la structure des données.
On à pris l'habitude de résonner en terme d'enregistrement, mais avec le graphe il en est autrement.
Parfois on est contraint pour aller au plus vite ou au plus simple de biaiser la méthodologie Neo4j en ajoutant des propritétés nouvelles ou redondantes.

Personnellement dans mes graphes je n'utilise aucune relationships et je fais ce que je veux.
Pour une execution plus rapide je ne travaille qu'avec les APIs.
www.bontirage.com

Si tu sens le besoin d'inventer ne te prive pas. Ce qui compte c'est le résultat.

[frednotet]

Bonjour,

Euh je suis désolé mais j'ai du mal à comprendre ta réponse... Surtout lorsque tu me dis que tu "construits" tes graphes sans aucune relationship... Quel intérêt d'avoir un graphe dans ce cas ???

On Thursday, October 16, 2014 8:16:01 PM UTC+2, Philippe Baumard wrote:

Bonjour,

J'ai vu avec l'habitude qu'il faut être très malin avec la structure des données.
On à l'habitude de résonner en terme d'enregistrement, mais avec le graphe il en est autrement.

Parfois on est contraint pour aller au plus vite ou au plus simple de biaiser la méthodologie Neo4j en ajoutant des propritétés nouvelles ou redondantes.

Personnellement dans mes graphes je n'utilise aucune relationships et je fais ce que je veux.

Pour une execution plus rapidet je ne travaille qu'avec les APIs.

[Philippe Baumard]

En premier j'ai voulu profiter de la rapidité d'éxécution pour de gros volumes.
Je n'avais jamais travaillé auparavant avec un graphe mais avec SQL.

Ce que j'ai fais avec SQL je l'ai refais avec Neo4j.
Je peux facilement véhiculer mes graphes entre mon serveur de production et mon serveur d'exploitation.
Les méthodes d'accès aux données sont extrèmement simple à mettre au point par rapport au SQL.
L'association GWT et Neo4j fonctionne très fort.

Il est vrai que je n'ai pas besoin de mettre en place des relations complexes. Sur le moment j'ai cru en avoir besoin.
Mais tout depend de ce que l'on veut faire. Je crois aussi qu'il est très facile de s'embourber dans l'inconnu la première fois.

[Cédric Fauvet]

Bonjour,

Il n'est à priori pas possible de trier sur une relation ou une propriété de relation en cypher, du coup il peut être une bonne idée de représenter chaque relation par en fait deux relations et un noeud, afin de pouvoir trier sur les noeuds intermédiaires.

Exemple :

Aujourd'hui :

(A)-[:relie]-(B)

Après modif :

(A)--(relie)--(B)

Il est sans doute de bon aloi de labéliser le le noeud (relie) d'une manière discriminante afin de le retrouver facilement dans tes requêtes, tu peux aussi lui affecter un poids afin d'agir sur ton ordre de tri.

Une seconde possibilité serait de travailler le tri en java dans un algo dédié.

D'une manière plus générale, quel est ton cas d'usage ? Pourquoi ce besoin de tri sur des relations ?

A bientôt

[frednotet]

Merci,

mon usage final est de "dessiner" une carte (www.musimap.net). Chaque noeud est positionné les uns par rapport aux autres dans un ordre précis. Considérons chacun de ces noeuds comme un rectangle qui peut être avant ou après un autre, mais également à l'intérieur ou regroupant d'autres. Actuellement, je récupère déjà mon arbre depuis les parents jusqu'aux "arrière-arrière-*-arrière-petits enfants" (via la relation :INSIDE); mais j'ai besoin à chaque niveau de trier ces enfants via la relation ":AFTER" pour pouvoir afficher ensuite l'ordre décidé par les encodeurs qui n'est pas alphabétique ni en fonction d'une propriété déjà existante.

Je comprends donc bien que ce n'est pas possible actuellement selon mon "schéma" actuel, mais je préfère alors simplement rajouter une propriété numérique à chacun de mes noeuds et utiliser cette propriété pour trier l'ordre d'affichage plutôt que de représenter une relation par un nouveau noeud. Je pars du principe que mes données sont stockées telles qu'elles existent et non pas d'une façon qu'il convient pour "contourner un problème". De plus, si par la suite cette fonctionnalité arrive, tout sera déjà prêt :)

C'est tout de même bizarre cette limitation; j'imaginais que dans un système de graph, cela y serait inclus... ;)

[Philippe Baumard]

[mais je préfère alors simplement rajouter une propriété numérique à chacun de mes noeuds et utiliser cette propriété pour trier]

C'est ce qu'il faut faire!

[Florent Biville]

L'algorithme que tu tentes de spécifier en Cypher semble se rapprocher beaucoup d'un tri topologique.

Mais comme déjà expliqué précédemment, ça risque d'être compliqué en Cypher, utiliser le framework de traversée sera sans doute plus simple, si tu ne souhaites pas altérer ton modèle de données.

Sur la question de la limitation, il se trouve que tu te sers des relations comme relations d'inclusion et d'antériorité, et donc que tu représentes une notion d'ordre. Cela dit, c'est complètement spécifique au domaine métier que tu es en train de modéliser, d'où l'absence de tri standard sur les relations.

En d'autres termes, une relation dans un graphe n'implique pas nécessairement une relation d'ordre entre les éléments.

2014-10-17 11:38 GMT+02:00 'Philippe Baumard' via Neo4jFr <neo...@googlegroups.com>:

[mais je préfère alors simplement rajouter une propriété numérique à chacun de mes noeuds et utiliser cette propriété pour trier]

C'est ce qu'il faut faire!

--

Florent Biville (@fbiville)
Associate developer at Lateral Thoughts

www.lateral-thoughts.com