Hello.
I would like to talk about the ordering of the nodes in the graph.
There are two entities: category and product.
N categories can contain N products.
The same product can simultaneously belong to N categories.
Task: to be able to manage the order of products in a subset of products of each category.
Possible solutions.
First.
Each category has a category.products edge pointing to the products belonging to this category. Order determines by the facet (priority = 1,2,3,4 … etc.).
Schema:
category.name: string.
category.products: uid.
product.name: string.
Data:
_: c1 <category.name> "category1" .
_: c2 <category.name> "category2" .
_: c3 <category.name> "category3" .
_: p1 <product.name> "product1" .
_: p2 <product.name> "product2" .
_: p3 <product.name> "product3" .
_: p4 <product.name> "product4" .
_: p5 <product.name> "product5" .
_: c1 <category.products> _: p1 (priority=1) .
_: c1 <category.products> _: p2 (priority=2) .
_: c1 <category.products> _: p3 (priority=3) .
_: c1 <category.products> _: p4 (priority=4) .
_: c1 <category.products> _: p5 (priority=5) .
_: c2 <category.products> _: p1 (priority=1) .
_: c2 <category.products> _: p2 (priority=2) .
_: c2 <category.products> _: p4 (priority=3) .
_: c2 <category.products> _: p5 (priority=4) .
_: c3 <category.products> _: p2 (priority=1) .
_: c3 <category.products> _: p4 (priority=2) .
_: c3 <category.products> _: p5 (priority=3) .
Benefits:
- simplicity of perception.
Disadvantages:
- facets do not have indexes and are not suitable for sorting
- if you change the order of the elements, you need to recalculate the priority (for example, if you move the last element to the top of the list, its priority should become 1, and all other priority + 1; maybe Dgraph has a built-in recalculation mechanism?)
Second.
Each category has a category.products edge pointing to the first product belonging to this category. Order determines by the edge product.next of each particular product. Each edge has a facet (<category.uid> = true) for the ability to get a “chain” of products of a particular category.
Schema:
category.name: string .
category.products: uid .
product.name: string .
product.next: uid .
Data:
_: c1 <category.name> "category1" .
_: c2 <category.name> "category2" .
_: c3 <category.name> "category3" .
_: p1 <product.name> "product1" .
_: p2 <product.name> "product2" .
_: p3 <product.name> "product3" .
_: p4 <product.name> "product4" .
_: p5 <product.name> "product5" .
_: c1 <category.products> _: p1 .
_: c2 <category.products> _: p1 .
_: c3 <category.products> _: p2 .
_: p1 <product.next> _: p2 (category1=true,category2=true) .
_: p2 <product.next> _: p3 (category1=true) .
_: p2 <product.next> _: p4 (category2=true,category3=true) .
_: p3 <product.next> _: p4 (category1=true) .
_: p4 <product.next> _: p5 (category1=true,category2=true,category3=true) .
Benefits:
- the ability to change the order of products by breaking old ties and creating new ones
Disadvantages:
- the need for multiple checks in the code when changing the order of products
- whether there is a edge between products
- if it does not exist, you must create it and specify the current category as a facet
- if there is, then you must add a new facet without losing existing ones
- whether there is a edge between products
- N facets at each edge looks strange
- even with a small number of categories and products, their connections begin to drive people crazy
Disadvantages of the second solution suggest an absurdity.
The task seems to be extremely burning, and for sure I’m not the first one to face it.
I would be grateful for any ideas and thoughts on this topic.
P.S.
Sorry for awful english.