Cacher le path d'une requête pour une utilisation future

[PrBifidus]

Bonjour à tous,

Je suis en train de créer une interface de configuration de produit qui va s'appuyer sur la modélisation de nomenclatures dans une base Neo4j.
Pour résumer, l'utilisateur va choisir le modèle de produit qu'il veut configurer. Il arrive alors sur une interface qui va présenter les différentes options, et l'impact de chacune d'elle sur le le prix du produit fini.

Les nomenclatures sont nombreuses et assez complexes (bon, ce n'est pas un projet big data quand même ;-)), et incluent de nombreux paramètres (type d'utilisateur, option tarifaire, date de production...).
Comme certains de ces paramètres sont connus au moment où l'utilisateur accède à l'interface de configuration, je me disais qu'il serait profitable de faire une première requête avec ces paramètres afin d'extraire un premier arbre qui correspondra aux différentes possibilités disponiblpe dans le contexte, et "mettre ce sous-graphe en cache" pour pouvoir simplifier les requêtes ultérieures.
Par exemple, un utilisateur ne va pas changer de type ou d'option tarifaire en cours de route, donc tous les paths qui ne concernent pas son type et son option tarifaire n'ont pas d'intérêt dans le contexte. Si on les élimine, le sous-arbre à requêter par la suite est plus simple.

J'ai bien compris qu'on pouvait chainer les requêtes et utiliser le résultat de la précédente comme contexte de la suivante. Mais, là, les requetes ultérieures sont déconnectées de la requêtes initiale (elles peuvent intervenir plusieurs minutes plus tard).
J'ai vu aussi qu'on pouvait créer des requêtes paramétrées pour améliorer les performances en évitant le recalcul du plan de requête. Mais est-ce que ça répond à mon besoin ? Et, d'ailleurs, est-ce que mon besoin est pertinent ?

Je suis preneur de tout lien ou conseil sur ce sujet.

Merci d'avance pour votre aide.

[Benoît Simard]

Bonjour

De mon PDV il n'y a pas besoin de cache ou de creation de sousgraph,  c'est juste le pattern qui devient de plus en plus précis non ?

Et plus le pattern est précis  plus la query sera rapide.

Sinon pour repondre a la question, il est possible de créer un array d'ID de noeud et de faire une clause where dans votre seconde query comme ceci : 

WHERE id (n) IN [1, 2 ,3 ..]

 

Avec ceci on travaille sur un sous graph.

Sent from my phone

[PrBifidus]

Merci Benoît.

Une fois que l'utilisateur est sur la page de configuration, le pattern ne se précise pas vraiment. Toutes les options sont présentées, avec pour chacune l'impact sur le prix si elle est modifiée.
Prenons un exemple, avec un produit qui existe en 2 matières (plastique et métal) et dont le prix varie en fonction de la quantité. sur l'interface, j'aurai (en simplifiant) un slider pour faire varier la quantité, et un bouton radio pour choisir entre plastique et métal.
Quelles que soient les valeurs choisies, les possibilités ne bougeront pas.
En revanche, si j'ai choisi plastique pour 100 pièces, j'aurais une indication "+5.00€" sous "métal" pour indiqué que, avec cette quantité de 100 ex, la version métal côute 5€ de plus. Et sous la quantité de 200, j'aurais "-0.50€" pour indiquer que, sur la version plastique, une commande de 200 ex au lieu de 100 réduit le prix unitaire de 0.50€.
Le pattern est donc toujours aussi précis, seules les valeurs des paramètres varient.

En termes de performances, quelle serait la meilleure solution en théorie :
- parcourir tout le graphe avec la pattern complet à chaque changement d'option ?
- faire une première requête pour récupérer uniquement les id possibles, puis, à chaque changement d'option, passer cette liste avec les paramètres (qté et matière, dans mon exemple) à une requête plus simple qui va calculer les prix ?

[Benoît Simard]

Re

Si chaque valeur des éléments de configuration est un noeud dans le graph, plus l'utlisateur va configurer le produit, plus le pattern va etre précis.

De plus a ce que j'ai compris, l'utilisateur va toujours partir d'un noeud produit, donc vous n'allez pas parcourir tous le graph a chaque fois, mais juste vous propager a partir de ce noeud.

Je pense qu'il faut voir la modélisation.

Sincèrement