-
Notifications
You must be signed in to change notification settings - Fork 41
Review of the page Comparing relational to graph database #497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
AlexicaWright
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice and concise! I left some comments :)
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
| The data stays remarkably similar to its form in the real world - small, normalized, yet richly connected entities. | ||
| This allows you to query and view your data from any imaginable point of interest, supporting many different use cases. | ||
| By assembling nodes and relationships into connected structures, graph databases enable building models that map closely to a problem domain. | ||
| Each node contains relationships to other nodes, and these relationship are organized by type and direction, holding or not additional attributes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this sentence? Nodes don't contain the actual relationships to other nodes and both nodes and relationships can have properties, if that's what "attributes" here refers to.
| Each node (entity or attribute) in the graph database model directly and physically contains a list of relationship records that represent the relationships to other nodes. | ||
| These relationship records are organized by type and direction and may hold additional attributes. | ||
| Whenever you run the equivalent of a _JOIN_ operation, the graph database uses this list, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations. | ||
| Whenever you run xref:cypher-intro/cypher-sql.adoc[the equivalent of a `JOIN` operation], the graph database uses these relationships, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this simplification is technically accurate, or whether it actually matters? To be safe, I'd just use the original.
|
|
||
| As you can probably imagine from the structural differences discussed above, the data models for relational versus graph are very different. | ||
| The straightforward graph structure results in much simpler and more expressive data models than those produced using traditional relational or other NoSQL databases. | ||
| If you are familiar with the relational data model that has tables, columns, relationship cardinalities, and other components, graph data modeling will not seem entirely foreign. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the models are very different?
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
| In Cypher, the syntax remains concise and focused on domain components and their connections, thus expressing the pattern to find or create data more visually and clearly. | ||
|
|
||
| Other clauses outside of the basic pattern matching still look very similar to SQL, as Cypher was built on the predecessor language’s foundation. | ||
| You can see the similarities and differences in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a missing link here?
|
|
||
| Other clauses outside of the basic pattern matching still look very similar to SQL, as Cypher was built on the predecessor language’s foundation. | ||
| You can see the similarities and differences in | ||
| If you want to learn how to move your data from a relational database to a graph, see |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here?
Co-authored-by: Jessica Wright <[email protected]>
AlexicaWright
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more suggestions!
| These relationship records are organized by type and direction and may hold additional attributes. | ||
| Whenever you run the equivalent of a _JOIN_ operation, the graph database uses this list, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations. | ||
| By assembling nodes and relationships into connected structures, graph databases enable building models that map closely to a problem domain. | ||
| Whenever you run xref:cypher-intro/cypher-sql.adoc[the equivalent of a `JOIN` operation], the graph database uses this list, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But now the list doesn't refer to anything, since it hasn't been defined.
|
|
||
| As you can probably imagine from the structural differences discussed above, the data models for relational versus graph are very different. | ||
| The straightforward graph structure results in much simpler and more expressive data models than those produced using traditional relational or other NoSQL databases. | ||
| Despite similarities, the design of a xref:data-modeling/index.adoc[graph data model] still needs to be based upon requirements for access, queries, performance expectation, and business logic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But no similarities have been mentioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about something like:
The data models for relational databases and graph databases are vastly different, as a result of the structural differences described earlier/previously/above.
The graph model needs to consider access requirements, expected queries and performance, as well as business logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still applies, no similarities are mentioned, only differences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry, I forgot to update this one
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
| By assembling nodes and relationships into connected structures, graph databases enable building models that map closely to a problem domain. | ||
| Whenever you run xref:cypher-intro/cypher-sql.adoc[the equivalent of a `JOIN` operation], the graph database uses this list, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations. | ||
|
|
||
| This ability to pre-materialize relationships into the database structure allows Neo4j to provide performance of several orders of magnitude above others, especially for join-heavy queries, allowing users to leverage a _minutes to milliseconds_ advantage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, the youtube video is NINE years old, maybe there is something slightly more updated we could use?
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
Co-authored-by: Jessica Wright <[email protected]>
AlexicaWright
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some more comments, I know you love them ;)
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
|
|
||
| In the above relational example, we search the Person table on the left (potentially millions of rows) to find the user Alice and her person ID of 815. Then, we search the Person-Department table (orange middle table) to locate all the rows that reference Alice's person ID (815). Once we retrieve the 3 relevant rows, we go to the Department table on the right to search for the actual values of the department IDs (111, 119, 181). | ||
| Now we know that Alice is part of the 4Future, P0815, and A42 departments. | ||
| . Search the `Employees` table (potentially with millions of rows) to find the user Alice and her ID of 815. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Millions of rows? What company has millions of employees?
modules/ROOT/pages/appendix/graphdb-concepts/graphdb-vs-rdbms.adoc
Outdated
Show resolved
Hide resolved
Co-authored-by: Jessica Wright <[email protected]>
AlexicaWright
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! One broken link and one comment to address.
|
|
||
| As you can probably imagine from the structural differences discussed above, the data models for relational versus graph are very different. | ||
| The straightforward graph structure results in much simpler and more expressive data models than those produced using traditional relational or other NoSQL databases. | ||
| Despite similarities, the design of a xref:data-modeling/index.adoc[graph data model] still needs to be based upon requirements for access, queries, performance expectation, and business logic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still applies, no similarities are mentioned, only differences.
| In Cypher, the syntax remains concise and focused on domain components and their connections, thus expressing the pattern to find or create data more visually and clearly. | ||
|
|
||
| Other clauses outside of the basic pattern matching still look very similar to SQL, as Cypher was built on the predecessor language’s foundation. | ||
| You can see the similarities and differences in ref:/cypher-intro/cypher-sql.adoc[Comparing Cypher with SQL]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| You can see the similarities and differences in ref:/cypher-intro/cypher-sql.adoc[Comparing Cypher with SQL]. | |
| You can see the similarities and differences in xref:/cypher-intro/cypher-sql.adoc[Comparing Cypher with SQL]. |
|
Thanks for the documentation updates. The preview documentation has now been torn down - reopening this PR will republish it. |
AlexicaWright
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks @lidiazuin 👍
* Review of the page Comparing relational to graph database * Apply suggestions from code review Co-authored-by: Jessica Wright <[email protected]> * Fixes after review * Apply suggestions from code review Co-authored-by: Jessica Wright <[email protected]> * Apply suggestions from code review Co-authored-by: Jessica Wright <[email protected]> * fixes after review * updated package log * updated package-lock * fixes after review --------- Co-authored-by: Jessica Wright <[email protected]>
* Review of the page Comparing relational to graph database (#497) * Review of the page Comparing relational to graph database * Apply suggestions from code review Co-authored-by: Jessica Wright <[email protected]> * Fixes after review * Apply suggestions from code review Co-authored-by: Jessica Wright <[email protected]> * Apply suggestions from code review Co-authored-by: Jessica Wright <[email protected]> * fixes after review * updated package log * updated package-lock * fixes after review --------- Co-authored-by: Jessica Wright <[email protected]> * fixing issues --------- Co-authored-by: Jessica Wright <[email protected]>
No description provided.