I have recently started looking at a use case where neo4j’s Graph Db could be used to capture data and answer data relationship queries which could possibly be combined with AI.
I have a lot to learn yet! In the mean time I have had a quick look at the GraphGists listed, as initially I am looking at where to start i.e. how do I present the use case as a proof of concept to the stakeholders, in order to fully develop it? Supply chain and data reporting is the area I am focused on, if there is any other material out there that could help, especially around use cases/projects that explain why and how the approach was taken, it would be much appreciated.
The key thing for Graph DB's is that they handled many-to-many relationships much better than traditional "relational" DB's.
In the real world, especially where humans are involved, a many-to-many relationship occurs frequently and quite naturally.
The 6 degrees of Kevin Bacon is one example. Another is MS's North Wind demo DB ( Northwind sample database | YugabyteDB Docs ) which is a mess.... e.g. many-to-many relationship between suppliers and products.
One thing to try, is get somebody to draw a picture of the schema and then translate it into a graph DB.
Hi @amibening , a very good question. I have faced this situation a lot, not just for Neo4j database for any type of database. The very first step is to understand the pain-points currently you/the company as a whole is facing. What the business is lacking in terms of time-to-market. Then the Data Science part, how the Data Scientist are looking at the data.
Many-to-Many relationships exists in all the database, if the data is connected to many other data. so, there is no way of coming out of it. Traditional database are still working great if the query is optimized. remember 99% problem are with the SQL query not with the database.
There is a false claim that migrate your database to NoSQL, and it will work wonders. Simple to say, but you will face hurdles along the way. ( I am not saying don't test in Neo4j).
What is your database ?? OLTP or OLAP ? all this have be considered.
One main issue, is having to re-write the application to use Neo4j. This depends on the project budget, application development timeline, proof-of-concept, migrating the existing data to new database, Testing, QA etc etc.
When you are presenting a story-telling to the stakeholders, you have consider these points.
Note - My answer is not to de-motivate you. I just want to make sure, you are putting down the correct points. My golden rule, "If ain't broken, don't fix it" .
To explain a bit more....
If you have a supply chain, I imagine you are facing sort of what the Microsoft Northwind Demo DB shows. Many many-to-many relationships, which makes it harder to make queries.
With a RDBMS, it's highly tempting to just make the schema to be one-to-one relationship, which is far more convenient (or after making some simplifying assumptions) but paints you into a corner.
I think unless you really got the schema nailed down (which is hard unless it's a simple situation), a Graph DB comes in handy.
What has been said in the military: "No battle plan survives after the first contact with the enemy."
Similarly, no schema survives first contact with a real user...