11 ms·

The film industry example makes sense. Partially duplicative tables make development confusing. Do you still feel there is an advantage of graph over relation

by srd31 9y ago

The film industry example makes sense. Partially duplicative tables make development confusing. Do you still feel there is an advantage of graph over relational when we have a known schema and known relationships without deep recursive relationships. For example, an inventory tracking system, we have items, customers, deliveries,etc...? I like the idea of being able to throw some metadata onto any of those tables quickly during prototyping, but my gut feeling is that long term we run into the need to be more structured and explicit like we do with a relational DB. It reminds me somewhat of the tradeoffs with NoSQL DBs during development

mrjn 9y ago
Not only do I think there's a lot of benefit in representing data for which the schema is already fixed, we've actually gone to the extent of showing this by building a whole replica website for Stack Overflow. https://github.com/dgraph-io/graphoverflow https://github.com/dgraph-io/graphoverflow (unmaintained, so please don't complain if it doesn't work :-)). If you build systems like inventory tracking, question answering, etc., the hard logic of relevant data retrieval can either lie in your application or within your DB. Former is the case when you use relational DBs, latter is the case when you use graph DBs. With graph DB, you can put the data together quickly, but then have the DB do the hardlifting of "given a customer, find me all the items and the locations of delivery" (just random Q that I spent 2 seconds, not representative of real workload); or "given a question, find me all the answers, sorted by a score; top 5 comments on these answers sorted by date, with a count of total comments, count of likes, count of dislikes, etc." (real workload for QA sites). Then the application iteration becomes largely a factor of query iteration, not backend logic iteration. ^ And that's solid! That kind of stuff is what makes developers love JS over C++ (random comparison).

by srd31 9y ago

mrjn 9y ago

Not only do I think there's a lot of benefit in representing data for which the schema is already fixed, we've actually gone to the extent of showing this by building a whole replica website for Stack Overflow. https://github.com/dgraph-io/graphoverflow https://github.com/dgraph-io/graphoverflow (unmaintained, so please don't complain if it doesn't work :-)). If you build systems like inventory tracking, question answering, etc., the hard logic of relevant data retrieval can either lie in your application or within your DB. Former is the case when you use relational DBs, latter is the case when you use graph DBs. With graph DB, you can put the data together quickly, but then have the DB do the hardlifting of "given a customer, find me all the items and the locations of delivery" (just random Q that I spent 2 seconds, not representative of real workload); or "given a question, find me all the answers, sorted by a score; top 5 comments on these answers sorted by date, with a count of total comments, count of likes, count of dislikes, etc." (real workload for QA sites). Then the application iteration becomes largely a factor of query iteration, not backend logic iteration. ^ And that's solid! That kind of stuff is what makes developers love JS over C++ (random comparison).