Best practices for developing an application with Neo4J












0















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.










share|improve this question


















  • 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






  • 1





    Of interest : Google neo4j whiteboard

    – Guy Coder
    Nov 22 '18 at 15:59


















0















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.










share|improve this question


















  • 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






  • 1





    Of interest : Google neo4j whiteboard

    – Guy Coder
    Nov 22 '18 at 15:59
















0












0








0








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.










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 22 '18 at 14:18









nishantvnishantv

2042722




2042722








  • 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






  • 1





    Of interest : Google neo4j whiteboard

    – Guy Coder
    Nov 22 '18 at 15:59
















  • 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






  • 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














1 Answer
1






active

oldest

votes


















1















...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.






share|improve this answer
























  • 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











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
});


}
});














draft saved

draft discarded


















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









1















...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.






share|improve this answer
























  • 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
















1















...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.






share|improve this answer
























  • 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














1












1








1








...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.






share|improve this answer














...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.







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen