Best practices for developing an application with Neo4J
I recently came across an application which uses NEO4j as the backend. In my experience with SQL and other Key-value based databases, I have developed an understanding(which could be refined) that other databases store data and your application derives the information while with NEO4J you store the information. This means that the logic of deriving the information is already captured in the model of NEO4J. I am not able to get my head around this because now I cannot have logic that can be composed and most importantly something that can be tested with unit tests. I can sure have component level tests using embedded neo4j but then that's not the same. Can someone please help me understand the application development philosophy/methodology with NEO4J.
neo4j
add a comment |
I recently came across an application which uses NEO4j as the backend. In my experience with SQL and other Key-value based databases, I have developed an understanding(which could be refined) that other databases store data and your application derives the information while with NEO4J you store the information. This means that the logic of deriving the information is already captured in the model of NEO4J. I am not able to get my head around this because now I cannot have logic that can be composed and most importantly something that can be tested with unit tests. I can sure have component level tests using embedded neo4j but then that's not the same. Can someone please help me understand the application development philosophy/methodology with NEO4J.
neo4j
1
I don't really agree withthe logic of deriving the information is already captured
I would agree withthe relationships between the information is already captured
. The simplest way I think about it is that you have a white board drawing of the data as a connected graph with circles and lines. When you explain the data you point at a circle and then follow the line to the next circle. When you have touched all of the circles that answer the question you are done. Same here, nodes are circles, lines are relationships, and questions are queries. Some queries need only Cypher, others Java.
– Guy Coder
Nov 22 '18 at 15:52
1
Of interest : Google neo4j whiteboard
– Guy Coder
Nov 22 '18 at 15:59
add a comment |
I recently came across an application which uses NEO4j as the backend. In my experience with SQL and other Key-value based databases, I have developed an understanding(which could be refined) that other databases store data and your application derives the information while with NEO4J you store the information. This means that the logic of deriving the information is already captured in the model of NEO4J. I am not able to get my head around this because now I cannot have logic that can be composed and most importantly something that can be tested with unit tests. I can sure have component level tests using embedded neo4j but then that's not the same. Can someone please help me understand the application development philosophy/methodology with NEO4J.
neo4j
I recently came across an application which uses NEO4j as the backend. In my experience with SQL and other Key-value based databases, I have developed an understanding(which could be refined) that other databases store data and your application derives the information while with NEO4J you store the information. This means that the logic of deriving the information is already captured in the model of NEO4J. I am not able to get my head around this because now I cannot have logic that can be composed and most importantly something that can be tested with unit tests. I can sure have component level tests using embedded neo4j but then that's not the same. Can someone please help me understand the application development philosophy/methodology with NEO4J.
neo4j
neo4j
asked Nov 22 '18 at 14:18
nishantvnishantv
2042722
2042722
1
I don't really agree withthe logic of deriving the information is already captured
I would agree withthe relationships between the information is already captured
. The simplest way I think about it is that you have a white board drawing of the data as a connected graph with circles and lines. When you explain the data you point at a circle and then follow the line to the next circle. When you have touched all of the circles that answer the question you are done. Same here, nodes are circles, lines are relationships, and questions are queries. Some queries need only Cypher, others Java.
– Guy Coder
Nov 22 '18 at 15:52
1
Of interest : Google neo4j whiteboard
– Guy Coder
Nov 22 '18 at 15:59
add a comment |
1
I don't really agree withthe logic of deriving the information is already captured
I would agree withthe relationships between the information is already captured
. The simplest way I think about it is that you have a white board drawing of the data as a connected graph with circles and lines. When you explain the data you point at a circle and then follow the line to the next circle. When you have touched all of the circles that answer the question you are done. Same here, nodes are circles, lines are relationships, and questions are queries. Some queries need only Cypher, others Java.
– Guy Coder
Nov 22 '18 at 15:52
1
Of interest : Google neo4j whiteboard
– Guy Coder
Nov 22 '18 at 15:59
1
1
I don't really agree with
the logic of deriving the information is already captured
I would agree with the relationships between the information is already captured
. The simplest way I think about it is that you have a white board drawing of the data as a connected graph with circles and lines. When you explain the data you point at a circle and then follow the line to the next circle. When you have touched all of the circles that answer the question you are done. Same here, nodes are circles, lines are relationships, and questions are queries. Some queries need only Cypher, others Java.– Guy Coder
Nov 22 '18 at 15:52
I don't really agree with
the logic of deriving the information is already captured
I would agree with the relationships between the information is already captured
. The simplest way I think about it is that you have a white board drawing of the data as a connected graph with circles and lines. When you explain the data you point at a circle and then follow the line to the next circle. When you have touched all of the circles that answer the question you are done. Same here, nodes are circles, lines are relationships, and questions are queries. Some queries need only Cypher, others Java.– Guy Coder
Nov 22 '18 at 15:52
1
1
Of interest : Google neo4j whiteboard
– Guy Coder
Nov 22 '18 at 15:59
Of interest : Google neo4j whiteboard
– Guy Coder
Nov 22 '18 at 15:59
add a comment |
1 Answer
1
active
oldest
votes
...other databases store data and your application derives the information while with NEO4J you store the information.
Hmmm.... Define data and define information. Mostly it goes: Data is something that requires further processing to become information (that is, something informative - something you can derived some conclusion or insights from).
Anyhow, doubt this has anything to do with Graph databases vs relational/aggregate databases. A database, as the name suggests, stores data.
This means that the logic of deriving the information is already captured in the model of NEO4J.
I'm not sure what you mean by "the logic... is already captured". Some queries are much easier with Neo+Cypher that with say SQL; like "Find all the friends of my friends that live in Berlin", but I would hardly relate this to 'logic'.
I cannot have logic that can be composed and most importantly something that can be tested with unit tests.
What do you mean by 'logic that can be composed'? And unit tests has nothing to do with this I'm afraid - there's no logic being tested if you talk about graph vs other databases.
Can someone please help me understand the application development philosophy/methodology with NEO4J.
There's really not much to it. Neo4J is a database like any other database, only that it uses a different model from relational/aggregate databases.
To highlight two of its strengths:
No joins - That's a pain point with relational/aggregate databases, especially with complex queries. Essentially, nearly all system involve a data model that is a graph (you only need one many-to-many relationship in your data model for that), and not using a graph database is a form of dimensionality reduction. The reasons relational databases prevailed for so many years is nothing short of a set of historical coincidences.
Easier DB migrations - and that's for being a schema-less data base. You ripe the same benefits with any other schema-less database.
I strongly recommend you read the 'NOSQL Overview' appendix of the free Graph Databases. It focus on a lot of these points.
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53432929%2fbest-practices-for-developing-an-application-with-neo4j%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
...other databases store data and your application derives the information while with NEO4J you store the information.
Hmmm.... Define data and define information. Mostly it goes: Data is something that requires further processing to become information (that is, something informative - something you can derived some conclusion or insights from).
Anyhow, doubt this has anything to do with Graph databases vs relational/aggregate databases. A database, as the name suggests, stores data.
This means that the logic of deriving the information is already captured in the model of NEO4J.
I'm not sure what you mean by "the logic... is already captured". Some queries are much easier with Neo+Cypher that with say SQL; like "Find all the friends of my friends that live in Berlin", but I would hardly relate this to 'logic'.
I cannot have logic that can be composed and most importantly something that can be tested with unit tests.
What do you mean by 'logic that can be composed'? And unit tests has nothing to do with this I'm afraid - there's no logic being tested if you talk about graph vs other databases.
Can someone please help me understand the application development philosophy/methodology with NEO4J.
There's really not much to it. Neo4J is a database like any other database, only that it uses a different model from relational/aggregate databases.
To highlight two of its strengths:
No joins - That's a pain point with relational/aggregate databases, especially with complex queries. Essentially, nearly all system involve a data model that is a graph (you only need one many-to-many relationship in your data model for that), and not using a graph database is a form of dimensionality reduction. The reasons relational databases prevailed for so many years is nothing short of a set of historical coincidences.
Easier DB migrations - and that's for being a schema-less data base. You ripe the same benefits with any other schema-less database.
I strongly recommend you read the 'NOSQL Overview' appendix of the free Graph Databases. It focus on a lot of these points.
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
add a comment |
...other databases store data and your application derives the information while with NEO4J you store the information.
Hmmm.... Define data and define information. Mostly it goes: Data is something that requires further processing to become information (that is, something informative - something you can derived some conclusion or insights from).
Anyhow, doubt this has anything to do with Graph databases vs relational/aggregate databases. A database, as the name suggests, stores data.
This means that the logic of deriving the information is already captured in the model of NEO4J.
I'm not sure what you mean by "the logic... is already captured". Some queries are much easier with Neo+Cypher that with say SQL; like "Find all the friends of my friends that live in Berlin", but I would hardly relate this to 'logic'.
I cannot have logic that can be composed and most importantly something that can be tested with unit tests.
What do you mean by 'logic that can be composed'? And unit tests has nothing to do with this I'm afraid - there's no logic being tested if you talk about graph vs other databases.
Can someone please help me understand the application development philosophy/methodology with NEO4J.
There's really not much to it. Neo4J is a database like any other database, only that it uses a different model from relational/aggregate databases.
To highlight two of its strengths:
No joins - That's a pain point with relational/aggregate databases, especially with complex queries. Essentially, nearly all system involve a data model that is a graph (you only need one many-to-many relationship in your data model for that), and not using a graph database is a form of dimensionality reduction. The reasons relational databases prevailed for so many years is nothing short of a set of historical coincidences.
Easier DB migrations - and that's for being a schema-less data base. You ripe the same benefits with any other schema-less database.
I strongly recommend you read the 'NOSQL Overview' appendix of the free Graph Databases. It focus on a lot of these points.
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
add a comment |
...other databases store data and your application derives the information while with NEO4J you store the information.
Hmmm.... Define data and define information. Mostly it goes: Data is something that requires further processing to become information (that is, something informative - something you can derived some conclusion or insights from).
Anyhow, doubt this has anything to do with Graph databases vs relational/aggregate databases. A database, as the name suggests, stores data.
This means that the logic of deriving the information is already captured in the model of NEO4J.
I'm not sure what you mean by "the logic... is already captured". Some queries are much easier with Neo+Cypher that with say SQL; like "Find all the friends of my friends that live in Berlin", but I would hardly relate this to 'logic'.
I cannot have logic that can be composed and most importantly something that can be tested with unit tests.
What do you mean by 'logic that can be composed'? And unit tests has nothing to do with this I'm afraid - there's no logic being tested if you talk about graph vs other databases.
Can someone please help me understand the application development philosophy/methodology with NEO4J.
There's really not much to it. Neo4J is a database like any other database, only that it uses a different model from relational/aggregate databases.
To highlight two of its strengths:
No joins - That's a pain point with relational/aggregate databases, especially with complex queries. Essentially, nearly all system involve a data model that is a graph (you only need one many-to-many relationship in your data model for that), and not using a graph database is a form of dimensionality reduction. The reasons relational databases prevailed for so many years is nothing short of a set of historical coincidences.
Easier DB migrations - and that's for being a schema-less data base. You ripe the same benefits with any other schema-less database.
I strongly recommend you read the 'NOSQL Overview' appendix of the free Graph Databases. It focus on a lot of these points.
...other databases store data and your application derives the information while with NEO4J you store the information.
Hmmm.... Define data and define information. Mostly it goes: Data is something that requires further processing to become information (that is, something informative - something you can derived some conclusion or insights from).
Anyhow, doubt this has anything to do with Graph databases vs relational/aggregate databases. A database, as the name suggests, stores data.
This means that the logic of deriving the information is already captured in the model of NEO4J.
I'm not sure what you mean by "the logic... is already captured". Some queries are much easier with Neo+Cypher that with say SQL; like "Find all the friends of my friends that live in Berlin", but I would hardly relate this to 'logic'.
I cannot have logic that can be composed and most importantly something that can be tested with unit tests.
What do you mean by 'logic that can be composed'? And unit tests has nothing to do with this I'm afraid - there's no logic being tested if you talk about graph vs other databases.
Can someone please help me understand the application development philosophy/methodology with NEO4J.
There's really not much to it. Neo4J is a database like any other database, only that it uses a different model from relational/aggregate databases.
To highlight two of its strengths:
No joins - That's a pain point with relational/aggregate databases, especially with complex queries. Essentially, nearly all system involve a data model that is a graph (you only need one many-to-many relationship in your data model for that), and not using a graph database is a form of dimensionality reduction. The reasons relational databases prevailed for so many years is nothing short of a set of historical coincidences.
Easier DB migrations - and that's for being a schema-less data base. You ripe the same benefits with any other schema-less database.
I strongly recommend you read the 'NOSQL Overview' appendix of the free Graph Databases. It focus on a lot of these points.
answered Nov 22 '18 at 21:35
IzhakiIzhaki
16.4k64876
16.4k64876
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
add a comment |
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
With this answer and comment from @Guy Coder I realize that NEO4J simplifies data relationships and hence the queries when compared to SQL. It does not take into its responsibility any more than that from a program when using SQL. Thanks for the useful resources as well
– nishantv
Nov 23 '18 at 9:59
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
Indeed. Just note that it's not black & white, it really depends on the problem at hand - sometimes a graph database will be an overkill compared to others; For example, for the purpose of storing sessions, something like Redis will most likely be a better choice.
– Izhaki
Nov 23 '18 at 11:28
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53432929%2fbest-practices-for-developing-an-application-with-neo4j%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I don't really agree with
the logic of deriving the information is already captured
I would agree withthe relationships between the information is already captured
. The simplest way I think about it is that you have a white board drawing of the data as a connected graph with circles and lines. When you explain the data you point at a circle and then follow the line to the next circle. When you have touched all of the circles that answer the question you are done. Same here, nodes are circles, lines are relationships, and questions are queries. Some queries need only Cypher, others Java.– Guy Coder
Nov 22 '18 at 15:52
1
Of interest : Google neo4j whiteboard
– Guy Coder
Nov 22 '18 at 15:59