Neo4j allows you to have entities, quite similar to what a row in a table is. The key difference, subjectively, is flexibility to declare relationships between these entities in an easier manner than in a relational database. Aggregates can be easily created using their query language, Cypher, which isn't too hard and too different from SQL.
Yet again, if read speeds are critical and you can live without immediate consistency, then a key value or a document database would do the job perfectly.
Surely, we will discuss that with the team to see how things go... guess we are probably gonna use Neo (or any other suitable graphdb) with the profile model as well.
Technically, NoSQL reffers mostly to non-relational databases, and a Graph DB is all about relations, so I would say a Graph is more SQL than a standard RDBMS is :))
Also Neo4J doesn't scale (main advantage of the NoSQL), some new graph databases does like DGraph and Neptune.
Is it not quite graph database use-case? I thought you would need graph DB when you need to traverse graph, like give me all friends of all friends of A (wherein relational DB you would join table on table N times so eventually you will run out of RAM), but graph DB literally traverse graph, so there is no penalty in memory.
That's true. It really depends what kind of queries someone wants to run. Even in current example, you could end up joining same table multiple times to get a desired result and graphs would do better than a relational database.
Actually the document model fits more cuz we don't actually need to traverse but to compose everything into one UI.
As in the pic, we show all the track workshops on the right side, and we calculate the percentage of the shown lessons of each workshop, so we need to get everything of each workshop at once.
But for the profile we have a similar case, each profile has dozens of tasks, quizze, and projects... and we will traverse them on demand (lazy-loaded).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Use neo4j! A NoSQL graph database. 😉😉😉
Hmmm, I read about the graph DBs... but how does it solve our problem?
I see the problem as an aggregate root of Track (de-normalized all in one model) which is what the document model solves.
How would the graph model look like?
Neo4j allows you to have entities, quite similar to what a row in a table is. The key difference, subjectively, is flexibility to declare relationships between these entities in an easier manner than in a relational database. Aggregates can be easily created using their query language, Cypher, which isn't too hard and too different from SQL.
Yet again, if read speeds are critical and you can live without immediate consistency, then a key value or a document database would do the job perfectly.
Thanks for the elaboration, very appreciated !
Surely, we will discuss that with the team to see how things go... guess we are probably gonna use Neo (or any other suitable graphdb) with the profile model as well.
Technically, NoSQL reffers mostly to non-relational databases, and a Graph DB is all about relations, so I would say a Graph is more SQL than a standard RDBMS is :))
Also Neo4J doesn't scale (main advantage of the NoSQL), some new graph databases does like DGraph and Neptune.
Neo4j and Amazon Neptune are slightly different breeds. They're technically triple store databases. But yeah. Other than that I agree with you.
Is it not quite graph database use-case? I thought you would need graph DB when you need to traverse graph, like give me all friends of all friends of A (wherein relational DB you would join table on table N times so eventually you will run out of RAM), but graph DB literally traverse graph, so there is no penalty in memory.
That's true. It really depends what kind of queries someone wants to run. Even in current example, you could end up joining same table multiple times to get a desired result and graphs would do better than a relational database.
Actually the document model fits more cuz we don't actually need to traverse but to compose everything into one UI.
As in the pic, we show all the track workshops on the right side, and we calculate the percentage of the shown lessons of each workshop, so we need to get everything of each workshop at once.
But for the profile we have a similar case, each profile has dozens of tasks, quizze, and projects... and we will traverse them on demand (lazy-loaded).