Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
4  
Hard to say... I don't know how you're using this data. You might have to try both out under different sized loads and measure which does better. –  FrustratedWithFormsDesigner Jun 13 '11 at 17:41
add comment

5 Answers

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
The question seems to be suggesting an anti-optimisation to me - it's optimising a kind of design/maintenance overhead if anything (describing the logical database structure to the DBMS), not performance. –  Steve314 Jun 13 '11 at 22:27
add comment

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.

share|improve this answer
add comment

Absolutely yes. GraphDB allows you to speed up a lot many operations such as traversal. But the gain depends by the specific use case.

share|improve this answer
    
"Absolutely, but it depends." :) –  Ed Brannin Nov 13 '11 at 3:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.