A "graph business process" is borderline content free. All business processes can be expressed by graphs. What is a graph? A dynamic data structure. That is it.
So what is a "tree database"? A graph database with a bias for a specific ordering of its nodes. Does that make a tree database a query result (path traversal) in a graph database? The confusion of it all.
So imho one uses a "graph database" when (a) the domain is open ended, and (b) information is sketchy (precisely: incomplete), and as an important case in an open ended domain (c) we need to express a set of relationship types and ordering.
Semantic systems, for example, fit that description and can be reasonably considered as /fundamentally/ graph based. Some CRUD backend and OLAP on that domain likely does not.
To conclude, the naive impulse to reach for a graph db is likely induced by a recognition for needing something more expressive than a k/v, or doc store with secondary indexes, but fearing the dreaded RDBMS. Thus one "shoehorns" a static, completely captured, and fully described, domain unto a graph database cause E-R ain't sexy and SQL is a mystery. (Heads up: graph path expressions can get hairy too.)
I'm a fan of RDBMS (E-R) and SQL - it's cute and all for things like purchase orders and shopping carts and orders and receipts and the like. But for things like clinical informatics (even the non-semantic kind), graph traversal is easier than the unholy join from hell. For example.
You seem to know a hell of a lot about me and my particular problems from one, simple message. Tell me, oh great and powerful wizard, how does one acquire such awesome powers of wild-ass, baseless extrapolation?
So what is a "tree database"? A graph database with a bias for a specific ordering of its nodes. Does that make a tree database a query result (path traversal) in a graph database? The confusion of it all.
So imho one uses a "graph database" when (a) the domain is open ended, and (b) information is sketchy (precisely: incomplete), and as an important case in an open ended domain (c) we need to express a set of relationship types and ordering.
Semantic systems, for example, fit that description and can be reasonably considered as /fundamentally/ graph based. Some CRUD backend and OLAP on that domain likely does not.
To conclude, the naive impulse to reach for a graph db is likely induced by a recognition for needing something more expressive than a k/v, or doc store with secondary indexes, but fearing the dreaded RDBMS. Thus one "shoehorns" a static, completely captured, and fully described, domain unto a graph database cause E-R ain't sexy and SQL is a mystery. (Heads up: graph path expressions can get hairy too.)