moeed-k commented on issue #628:
URL: https://github.com/apache/age/issues/628#issuecomment-1405041310
If you think about a relational database table like the ones used in
PostgreSQL, you have a table with a name, and then some columns inside that
table. For graph databases, the table name can be thought of as the label of a
vertex (it describes the _type_ of a vertex). The properties on the other hand,
are like the columns of that table.
A vertex (also known as a node), is defined like this in a Cypher query:
**(v_alias : v_label {property1: value1, property2: value2 })**
Sticking to the 1st way you mentioned is faster than the second because it
helps filter out all unnecessary labels _before_ any properties are checked
within nodes of that label.
Even if you don't have concrete types, you can try assigning some labels
that will help make your queries faster (like how we can use a synthetic
primary key instead of an actually useful primary key in a relational
database). This comes under data modeling, and it is an important part of
designing graphs that can be efficiently queried. Here's a good blog post about
it:
https://maxdemarzi.com/2015/08/26/modeling-airline-flights-in-neo4j/
For the particular example you gave, here's something you could try:
```
SELECT *
FROM cypher('emp_graph',
$$
MATCH (:label1)-[r:similar]->(:label2)
return startNode(r), type(r), endNode(r)
$$
) as (V1 agtype, R agtype, V2 agtype);
```
Notice how the labels don't have an alias (slows down the query) and the
edge is unidirectional (query only searches for outgoing edges instead of both
ways).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@age.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
