> > As always, it really isn't that simple. Comparing "cold" queries is > probably not a good indicator of steady state performance, since > RDBMS's and Graph DB's have different models for file system access and > caching. Even different RDBMS's have dramatically different behaviors > in common queries (ever try to use MySQL for set operations - yuck.). > Factor in a wide range of SLAs needed for performance vs > availability vs affordability vs scalability vs adminstration costs, > and the equation gets a whole lot more complicated. >
Exactly. >From experience its possible to build a post/tag system in SQL that performs very well. However, the SQL model is inherently less flexible than the graph database model (what if I want to introduce a new relationship type, in a traditional SQL schema that would require new join tables etc...). > I'm sure there's a graphy-model for the tag/post example that could be > made smoking fast with Neo also. Hopefully! I suppose my question is "I would like to be able to harness a graph database to give flexibility and eloquence to our data model. However, can I query it efficiently without domain specific hacks and extra layers of code?". Al > > > > -------- Original Message -------- > Subject: Re: [Neo] How to efficiently query in Neo4J? > From: Michael Ludwig <mil...@gmx.de> > Date: Thu, April 08, 2010 6:02 pm > To: Neo user discussions <user@lists.neo4j.org> > Max De Marzi Jr. schrieb am 08.04.2010 um 16:48:18 (-0500) > [Re: [Neo] How to efficiently query in Neo4J?]: > > You know this is something that I think needs to be made clear... > > using just the graph is not the right way to go unless you have a > very > > special application. > > Some things are better not done in the graph. So I decided to keep > > that in tables, and just move the "person relationships" to the graph > > (works with, manages, knows, friends, etc). > > > > I treat the graph like a specialized index. Makes a lot more sense > > now, and I get the best of both worlds. > Exactly what I think. An iterable index, and a great one for the kind > of > graphy queries that cannot be done efficiently using sets and joins. > Any thoughts on what constitutes *graphiness*, if I may venture this > term? > -- > Michael Ludwig > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > [1]https://lists.neo4j.org/mailman/listinfo/user > > References > > 1. https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Dr Alastair James CTO James Publishing Ltd. http://www.linkedin.com/pub/3/914/163 www.worldreviewer.com WINNER Travolution Awards Best Travel Information Website 2009 WINNER IRHAS Awards, Los Angeles, Best Travel Website 2008 WINNER Travolution Awards Best New Online Travel Company 2008 WINNER Travel Weekly Magellan Award 2008 WINNER Yahoo! Finds of the Year 2007 "Noli nothis permittere te terere!" _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
