Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm starting to think that a lot of my tables could be replaced by only a graph db:
For example: I have 4 tables: accounts, votes, posts, relationships
but I can represent all these in a graph table with different edges,
NODE1 -> type of relation -> NODE2 account -> vote_+1 -> post account -> wrote -> post account -> friend -> account2
is there a difference of performance or other between them?
you can always represent relational data in graph form
the key is how are you using the data - mostly transactional updates, mostly graph-traversal queries?
if you have the time, do the conversion and profile your most common operations on both DBs
Actually, more than being graph DB it, what you describe is more like triplestore.
Triples subject -> predicate -> object, is what you're calling node1 -> type_of_relation -> node2.
If you combine that with inference engine, you can have very powerful tool. You'd be able not only query direct relations, but also implied relations. Like for example if you define rule like:
A -> grandparent -> B := (A -> parent -> x) && (x -> parent -> B)
They you can query grandparents, but you don't have to store that information in the DB. Of course this is very simple example, you can use it to build rather complicated relations.
The query language for triplestores is SPARQL, which is roughly based on SQL, and is quite simple to understand.
Is it a live system? Do you experience performance problems?
If no, don't bother changing everything to a graph database. If you don't gain anything at all, but instead take a lot of time away from other tasks, is it worth it? No.
If yes, identify (profile) whether or not it is the database being the problem. If it is, do some tests and check whether or not a graph database will be faster.
Don't just "optimize" without actually knowing whether or not it is worth it. The most important thing is to have a good architecture, and then you can later see if there is a problem. First when you find the problem, you start finding a better solution.
A many2many relationship helper table (a table with just two foreign keys) is a digraph adjacency list. A graph db may be advantageous if you have lots of m2m relationships, however it comes with the same cost as an m2m, which is always a bad thing unless they are truly necessary.
For example, account -> vote_+1 -> post and account -> friend -> account2 are m2m relationship, but account -> wrote -> post are not.
Absolutely yes. GraphDB allows you to speed up a lot many operations such as traversal. But the gain depends by the specific use case.
