Hey folks. Just published episode 5, introducing Cypher. Sorry for the long delay. The last episode was published 3 days before my daughter was born. Lots of sleepless nights doesn’t make for high quality single-handed video recording! Cheers! -Ryan
12:00 OMFG! this is so easy, why of god's green earth is this not how everyone is working with databases. It took me a long time to get comfortable with SQL syntax. It took me the time it took this guy to explain it at 1.5x speed to grok Cypher syntax.
Glad you're enjoying the technology! Cypher is similar to SQL in several ways, but as you point out, the syntax is a lot easier (and frankly, faster). If you want to learn and experiment with some basics, we have a guide you might be interested in here neo4j.com/whitepapers/getting-started-with-cypher/
Hey Ryan, This tutorial was simple, awesome and comprehensive. At the end though, it says "Next Up: Querying the Graph" The usual interval between the videos in the series have been 3-4 days but the next one seems to be taking a lot of time. Although the documentation and other resources on the official site are great, I am eagerly awaiting for the rest of the series.
He looks like a genius talking to a child with simple and small words. He is so holding himself not to go faster :) If you recognize this at the beginning of the video, you can never watch it as the same way :P
At 15:48 "As the size of your data increases with graph database, in particular with neo4j, it does not reduce the query times of querying the subsets of your graph." Shouldn't it be "... it does not INCREASE the query times of querying ... " ?
"This person is sad (no specific reason why)" "This person is how happy (no specific reason why)" It's so obvious why you should use a graph database with such sound logic! No downsides at all, I'm sure!
sure, technology choices is a game of trade offs. hopefully the reasons you'd want to use a graph database were apparent if you watched the other videos in the series. if not, feel feee to reach out at devrel@neo4j.com with more info on your usecases and we're happy to chat.
I didn't mean to come off as insulting. The video just missed an opportunity to explain why someone would actually do this. Replacing joins with different types of relationship terms isn't exactly convincing IMO. There have been countless "better than relational" databases and I'd like to see why Neo4j actually stands out. Perhaps, though, this is not the video where that explanation has to go. That's somewhat understandable except that this is the video on the neo4j page explaining why you would use graph instead of relational. It seems that if there is going to be a video prominently featured on that page it should actually summarized the rdbms vs. graph debate -- ideally with some downsides as a means of adding credibility to the discussion.
I think it was obvious. One can easily see and understand the relation ship within almost a min. in case of graph DB in this example, while for RDBMS, you need to go through fields, and relations, sometimes, and probably you can witness that it is still not understandable and we need to look at data.
Even in bigger and complex DBs RDBMS take many days to understand major relationships in a product, and still you have to ask lot of questions regarding relationship, even more where foreign keys are not formally there.
12:13 the query has an error, maybe someone else mentioned it but the: (u) - [:LED_BY] -> (l:Leader) ...should have been... (c) - [:LED_BY] -> (l:Leader) since u doesn't have that kind of relationship (LED_BY).
"better" than RDBMS seems to reference facts not in evidence. When comparing the SQL and GRAPH queries they were very similar. The joins were present in the GRAPH example but were essentially implied from the schema. Something an RDBMS could implement given proper/complete relationships. I'm sure GRAPH QL is just fine for some problems but there are so many more concerns when implementing OLAP vs OLTP systems.
Thanks for the feedback. You're correct that the queries are very similar for this particular query. We should have chosen one that's a bit more differentiated. In general, for highly connected data, many people find cypher to be a lot more user-friendly (for reading and crafting queries). You can see a number of comments here: twitter.com/nodesandrels. From a performance perspective, traversing relationships (memory pointer arithmetic) is a lot faster than JOINing with multiple index lookups -- that tends to be what drives many developers to Neo4j (and is in fact why the founders created the product ~17 years ago). If you have additional feedback, we'd love to hear it: devrel@neo4j.com.
Intro to Neo4J - here's 17 minutes telling you what's wrong with RDBMS. I'm nearly an hour into trying to find out about Neo4J *and I still hardly know anything about it*, "intuitive and fast" yeah, everyone says that. I'm not surprised you struggle to read diagrams like the one at 13:00, it's not a proper ER diagram, the keys aren't marked and there's no cardinality annotations. That's an F on any course. Northwind was first distributed with Access 1.0 btw.
Thanks for the feedback. What questions do you have about Neo4j? Note: you can find our online community and forum here: community.neo4j.com/. The most in-depth resource from a developer perspective is the O'Reilly book, available for free: graphdatabases.com/. (Note: Causal clustering is new since then, so admin/operations is best covered in the docs: neo4j.com/docs/).
This is so annoying... Why do you think it is called a relational database? The relations are IN the relations/tables not BETWEEN the relations/tables. You screw up the relational model. The relational model is about relations! And not in foreign keys (what a lot of people call relationships). A foreign key just means that the key-values of the node/object exists elsewhere, just a simple (=) join. Do your homework! And it is also hilarious... If I design a relational database I start with a graph (in Object Role Modelling) and translate it into a relational model (the reverse as described, but more strict and conform to the relational model). A relation/table is it's node, its key-values and its hierarchical (n:1) edges. The non-hierarchical (n:m) edges go into separate tables. Those non-hierarchical edges can have also attributes, thus key-values. But the non-hierarchical edges can have themselves also edges to other edges or to nodes. And then what? Do I understand it correctly? If I make the nodes round in stead of rectangular and I leave all the key-values out, it makes it more understandable? Come on! You cannot be serious! In ORM they are also round! But in ORM the edges can also be subjects (nodes?) in edges, which is also natural in language: "Mary thinks that Louise loves John". I think the statement that a graph model is easier to understand than e relational model is nonsense. It is one and the same. If you leave out details it looks simpler, so if you show all the key-values in the graph, but not in the relational model, the relational model looks simpler!
@@internet4543 I haven’t changed my mind. After more than 30 years of experience in building all types of graph applications my conclusion is that relational database are superior. I have some questions for you - Have you actually read what I wrote? - Are you open for dialogue about this subject? - What are your arguments why graph databases are easier?
@@internet4543 Relational databases are called so, because it’s all about relations (see my first comment). And it is NOT in what people call “relationships”, the foreign key relations! A table is in fact a large set of individual relations, every row is actually a compound of several binary or elementary relations, from the primary key to every column and / or foreign key. In a RDB you can actually model relations about relations, which in a lot of (labeled-property) graph databases is not possible (or only with the use of extensions). In triplet databases (RDF) this is possible. Only a limited subset of conceptual models can be mapped into a (labeled-property) graph model. A triplet store is equivalent to a relational model, where each individual relation is stored as a row, in stead of as a compound of relations (kind of pre-joined).
@@internet4543 The relationships (as entity relationship modeling calls them) between tables are not relations! The relationships are constraints, referential constraints, stating that you can only reference to relations/objects that already exist in the database. You can also interpret a referential constraint as that both keys (FK and PK) must represent the same relation/object. Thus the keys are the nodes in a graph database. The actual relations are the rows IN the tables. A table defines the type of relations you can store in it.These rows / relations are actually a compound of binary relations (from PK to every column value), each of which corresponds to an edge in a graph database. Hope this all helps.…
These six simple tutorials are much better for the core understanding of neo4j than hundreds of technical manuals. Thanks for the job well done.
Thanks Bahek.
Hey folks. Just published episode 5, introducing Cypher. Sorry for the long delay. The last episode was published 3 days before my daughter was born. Lots of sleepless nights doesn’t make for high quality single-handed video recording! Cheers! -Ryan
Belated Congratulations :)
Thanks for making this! Really appreciate the way you explain this from the start in a digestible way
12:00 OMFG! this is so easy, why of god's green earth is this not how everyone is working with databases. It took me a long time to get comfortable with SQL syntax. It took me the time it took this guy to explain it at 1.5x speed to grok Cypher syntax.
Glad you're enjoying the technology! Cypher is similar to SQL in several ways, but as you point out, the syntax is a lot easier (and frankly, faster). If you want to learn and experiment with some basics, we have a guide you might be interested in here neo4j.com/whitepapers/getting-started-with-cypher/
Thank you for this series.
I hope if be more episode about Graph Modeling.
+Mohamad Zaher Abd Ulmaula thanks for the feedback! -ryan
Hey Ryan,
This tutorial was simple, awesome and comprehensive. At the end though, it says "Next Up: Querying the Graph"
The usual interval between the videos in the series have been 3-4 days but the next one seems to be taking a lot of time.
Although the documentation and other resources on the official site are great, I am eagerly awaiting for the rest of the series.
I enjoyed the series, waiting for the next episode.
Thank you. I'm waiting for Episode 5 !
Long delay, but here it is! ua-cam.com/video/l76udM3wB4U/v-deo.html
This was very helpful. Thank you.
"HEEELLOOO!" :)
Thanks for this series...
where is the part #5 ?? thanks for this serie
Long delay, but here it is! ua-cam.com/video/l76udM3wB4U/v-deo.html
I can't understand what Ryan said at 15:45 . When the datasize in neo4j increases, query times doesn't get reduced? What do you imply?
I'm wating for the next episode, thanks!
Long delay, but here it is! ua-cam.com/video/l76udM3wB4U/v-deo.html
really good and detail explanation. enjoyed it.
excellent lecture really, very well explained. Bravo!
I really enjoy these presentation.
Really clear.
Thanks you.
Hi, Loved your videos, waiting for the next one. Thanks! :-)
Long delay, but here it is! ua-cam.com/video/l76udM3wB4U/v-deo.html
Thanks for the video,nice intro but I need more episodes !!! :)
Long delay, but here it is! ua-cam.com/video/l76udM3wB4U/v-deo.html
I just wanna know how about cardinalities restrictions in Cypher ?
He looks like a genius talking to a child with simple and small words. He is so holding himself not to go faster :)
If you recognize this at the beginning of the video, you can never watch it as the same way :P
Are you going to continue this series? It was really nice! Or you treat it as finished?
Long delay, but here is the next episode! ua-cam.com/video/l76udM3wB4U/v-deo.html
At 15:48 "As the size of your data increases with graph database, in particular with neo4j, it does not reduce the query times of querying the subsets of your graph."
Shouldn't it be "... it does not INCREASE the query times of querying ... " ?
"This person is sad (no specific reason why)"
"This person is how happy (no specific reason why)"
It's so obvious why you should use a graph database with such sound logic! No downsides at all, I'm sure!
sure, technology choices is a game of trade offs. hopefully the reasons you'd want to use a graph database were apparent if you watched the other videos in the series. if not, feel feee to reach out at devrel@neo4j.com with more info on your usecases and we're happy to chat.
I didn't mean to come off as insulting. The video just missed an opportunity to explain why someone would actually do this. Replacing joins with different types of relationship terms isn't exactly convincing IMO.
There have been countless "better than relational" databases and I'd like to see why Neo4j actually stands out. Perhaps, though, this is not the video where that explanation has to go. That's somewhat understandable except that this is the video on the neo4j page explaining why you would use graph instead of relational.
It seems that if there is going to be a video prominently featured on that page it should actually summarized the rdbms vs. graph debate -- ideally with some downsides as a means of adding credibility to the discussion.
I think it was obvious. One can easily see and understand the relation ship within almost a min. in case of graph DB in this example, while for RDBMS, you need to go through fields, and relations, sometimes, and probably you can witness that it is still not understandable and we need to look at data.
Even in bigger and complex DBs RDBMS take many days to understand major relationships in a product, and still you have to ask lot of questions regarding relationship, even more where foreign keys are not formally there.
12:13 the query has an error, maybe someone else mentioned it but the:
(u) - [:LED_BY] -> (l:Leader)
...should have been...
(c) - [:LED_BY] -> (l:Leader)
since u doesn't have that kind of relationship (LED_BY).
correct. thank you!
@@neo4j you're welcome - nice intro, by the way.
Thank you. It is wonderful.
I am not understanding the modeling ease part. If you provide names to the relationships in ER model, then it will be similar to the graph model only.
"better" than RDBMS seems to reference facts not in evidence. When comparing the SQL and GRAPH queries they were very similar. The joins were present in the GRAPH example but were essentially implied from the schema. Something an RDBMS could implement given proper/complete relationships. I'm sure GRAPH QL is just fine for some problems but there are so many more concerns when implementing OLAP vs OLTP systems.
Thanks for the feedback.
You're correct that the queries are very similar for this particular query. We should have chosen one that's a bit more differentiated.
In general, for highly connected data, many people find cypher to be a lot more user-friendly (for reading and crafting queries). You can see a number of comments here: twitter.com/nodesandrels. From a performance perspective, traversing relationships (memory pointer arithmetic) is a lot faster than JOINing with multiple index lookups -- that tends to be what drives many developers to Neo4j (and is in fact why the founders created the product ~17 years ago).
If you have additional feedback, we'd love to hear it: devrel@neo4j.com.
Can you post an example of how to migrate sql tables to neo4j like actual data?
neo4j.com/developer/guide-importing-data-and-etl/
I love that nasa's tweet only has 2 retweets and 7 likes 6:32
sure but does it have a driver for rust
only a community driven one - there is no official rust driver (yet)
Looking at multiple indexes is not painful. The computer does it. They don't feel pain. Personification not good idea.
u don't get the idea, computer and brain has same mechanism, the more logics to going through, the more resource and time to take the outcome
Thanks
Intro to Neo4J - here's 17 minutes telling you what's wrong with RDBMS. I'm nearly an hour into trying to find out about Neo4J *and I still hardly know anything about it*, "intuitive and fast" yeah, everyone says that.
I'm not surprised you struggle to read diagrams like the one at 13:00, it's not a proper ER diagram, the keys aren't marked and there's no cardinality annotations. That's an F on any course.
Northwind was first distributed with Access 1.0 btw.
Thanks for the feedback. What questions do you have about Neo4j? Note: you can find our online community and forum here: community.neo4j.com/. The most in-depth resource from a developer perspective is the O'Reilly book, available for free: graphdatabases.com/. (Note: Causal clustering is new since then, so admin/operations is best covered in the docs: neo4j.com/docs/).
The sound is not good enough (compared to the content)...
too much marketing; this is like a kid saying buy my candy and I promised you it is the best you've ever had.
you're talking about neo4j or graph databases in general?
Never end a video with "in the next video..." unless you already have the next video. Disappointing.
Long delay, but here it is! ua-cam.com/video/l76udM3wB4U/v-deo.html
This is so annoying...
Why do you think it is called a relational database? The relations are IN the relations/tables not BETWEEN the relations/tables. You screw up the relational model. The relational model is about relations! And not in foreign keys (what a lot of people call relationships). A foreign key just means that the key-values of the node/object exists elsewhere, just a simple (=) join. Do your homework!
And it is also hilarious... If I design a relational database I start with a graph (in Object Role Modelling) and translate it into a relational model (the reverse as described, but more strict and conform to the relational model). A relation/table is it's node, its key-values and its hierarchical (n:1) edges. The non-hierarchical (n:m) edges go into separate tables. Those non-hierarchical edges can have also attributes, thus key-values.
But the non-hierarchical edges can have themselves also edges to other edges or to nodes. And then what?
Do I understand it correctly? If I make the nodes round in stead of rectangular and I leave all the key-values out, it makes it more understandable? Come on! You cannot be serious! In ORM they are also round! But in ORM the edges can also be subjects (nodes?) in edges, which is also natural in language: "Mary thinks that Louise loves John".
I think the statement that a graph model is easier to understand than e relational model is nonsense. It is one and the same. If you leave out details it looks simpler, so if you show all the key-values in the graph, but not in the relational model, the relational model looks simpler!
@@internet4543 I haven’t changed my mind. After more than 30 years of experience in building all types of graph applications my conclusion is that relational database are superior.
I have some questions for you
- Have you actually read what I wrote?
- Are you open for dialogue about this subject?
- What are your arguments why graph databases are easier?
@@internet4543 Relational databases are called so, because it’s all about relations (see my first comment). And it is NOT in what people call “relationships”, the foreign key relations!
A table is in fact a large set of individual relations, every row is actually a compound of several binary or elementary relations, from the primary key to every column and / or foreign key.
In a RDB you can actually model relations about relations, which in a lot of (labeled-property) graph databases is not possible (or only with the use of extensions). In triplet databases (RDF) this is possible.
Only a limited subset of conceptual models can be mapped into a (labeled-property) graph model. A triplet store is equivalent to a relational model, where each individual relation is stored as a row, in stead of as a compound of relations (kind of pre-joined).
@@internet4543 The relationships (as entity relationship modeling calls them) between tables are not relations!
The relationships are constraints, referential constraints, stating that you can only reference to relations/objects that already exist in the database. You can also interpret a referential constraint as that both keys (FK and PK) must represent the same relation/object. Thus the keys are the nodes in a graph database.
The actual relations are the rows IN the tables. A table defines the type of relations you can store in it.These rows / relations are actually a compound of binary relations (from PK to every column value), each of which corresponds to an edge in a graph database.
Hope this all helps.…
you should may be choose palestine rather than israel in your table , awful