I want to implement database for following application:-
User creates task and assigns to other user who can furthur split it into subtasks and assign it to other users.creaking a tree like structure.
Should i use graph database or what?
You could use a graph database, or a plain old relational one:
Create a task:
Assign a task:
Split up a task:
Complete a task:
I would recommend PostgreSQL, as it can handle hierarchical data better than MySQL
In terms of SQL vs Graph databases, assuming your database can handle hierarchies well....
The major tradeoff is this schema flexibility vs reporting flexibility (it's more complicated than that, but that gives you an idea).
Basically SQL dbs usually operate over sets of tuples. Graph dbs usually operate over individual entities. Aggregation reporting is usually managed using MapReduce. SQL aggregation reporting tends to be done using well understood approaches (and on some clustered databases these have some similarity to MapReduce, but significant differences as well).
The big difference typically is in reporting. In general your reporting will be much easier on SQL. In general if you need or may need ad hoc reporting, SQL is the way to go. If you know for a fact that you never will, NoSQL, including graph dbs may be the way to go.
The best way to go IMO is to start with PostgreSQL with the idea that if you need to add a graph db as an auxiliary, you can do so. Many of these dbs have a great deal of utility when used as adjuncts to the RDBMS, but if you start with the RDBMS, it will be easier to add the other than it will be to go the other way around.
 Informix is an exception, as it operates over sets of objects. This leads to interesting results when child tables have more columns than parent tables. In that case, the rows of child tables will be returned when the parent table is queried using