Niels, on the query language side, I think that is both an advantage and a disadvantage. Advantage in that you get programmatic access to the storage engine like with the Java API or Gremlin, disadvantage in that you are essentially forced to script and optimize yourself.
I concur with you the SQL is not the way to go since it can't express the type of data structures and queries used in NOSQL, but I believe that declarative languages are MUCH easier to learn for users in 90% of the cases - and they are constant regardless of the surrounding software language used. Also, they open up for query optimizers and distribution and auto-indexing, which are things we want to explore with Cypher later on. Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sat, Oct 15, 2011 at 2:05 AM, Niels Hoogeveen <[email protected]> wrote: > > I concur. In my opinion Neo4j is more a storage engine with certain storage > features than a database management system. This is already exemplified by > the absence of a query language as primary interface. > The author is therefore wrong in his assessment that there is no separation > of logical model and physical model. There is no logical model, so the > separation is complete, any logical model can be bolted onto the physical > model, or can be stored in a separate repository. > In general, I think, NOSQL databases are more storage engine than database > management system. It's exactly the control over storage that forms the niche > NOSQL database operate in. Distributed key value lookup and tree/graph > traversals are typical application domains where SQL engines don't provide > the hooks to efficiently or scalably process certain questions or actions. > Niels > >> Date: Sat, 15 Oct 2011 01:12:58 +0200 >> From: [email protected] >> To: [email protected] >> Subject: Re: [Neo4j] Article: "The Coming SQL Collapse" >> >> My 2 cents: >> >> The Neo4j API is clean, open, and sort-of low level by intention. It is >> neither ugly, smelly, nor it does it violate anything. >> >> Neo4j in general is very stable. But, of course, if you try the latest >> snapshot, it may have bugs (as any software has). >> >> Since May 2010, we're developing a CMS based on Neo4j (structr) and do >> some graph-related projects. >> >> Coming from the Oracle world, I can only say that working with Neo4j is >> a revelation. >> >> Axel >> >> >> Am 14.10.2011 14:48, schrieb Tobias Ivarsson: >> > We had an interesting discussion about this internally at Neo Technology >> > today. We thought it might be of interest to the broader community. I don't >> > think the discussion is over, so it would be interesting to continue it on >> > the public mailing list. >> > >> > It regards the initial paragraphs of an article posted to dzone recently: >> > http://www.dzone.com/links/rss/the_coming_sql_collapse.html >> > It mentions Neo4j and how the author dislikes a common way of using Neo4j >> > for building applications. >> > >> > It would be interesting to hear suggestions on how to improve this. >> > >> > Forwarded conversation follows: >> > >> > On Fri, Oct 14, 2011 at 10:13 AM, Tobias Ivarsson< >> > [email protected]> wrote: >> > >> >> I found this while reading feeds in bed last night: >> >> >> >> *The Coming SQL Collapse* >> >> http://www.dzone.com/links/rss/the_coming_sql_collapse.html >> >> >> >> (Sent from Flipboard<http://flipboard.com>) >> >> >> >> >> >> The things he say about SQL vs NOSQL is not very interesting, but I'd like >> >> to raise what he says about Neo4j: >> >> >> >> I looked at neo4j briefly the other day, and quite predictably thought >> >>> ‘wow, this looks like a serious tinkertoy: it‘s basically a bunch of >> >>> nodes >> >>> where you just blob your attributes.‘ Worse than that, to wrap objects >> >>> around it, you have to have them explicitly incorporate their node class, >> >>> which is ugly, smelly, violates every law of separation of concerns and >> >>> logical vs. physical models. On the plus side, as I started to look at it >> >>> more, I realized that it was the perfect way to implement a backend for a >> >>> bayesian inference engine (more on that later). Why? Because inference >> >>> doesn‘t care particularly about all the droll requirements that are >> >>> settled >> >>> for you by SQL, and there are no real set operations to speak of. >> >> >> >> He attacks our pattern of building domain models with Neo4j, calling it >> >> "ugly", "smelly" and "in violation of every law of separation of concerns >> >> and logical vs. physical models". Is he right? My feeling is that he is >> >> brain washed with too many so called "best practices", but Neo4j has been >> >> my >> >> main model for a long time now, my perspective is likely skewed. I'd like >> >> to >> >> hear your thoughts. >> >> >> >> -- >> >> Tobias Ivarsson<[email protected]> >> >> >> > On Fri, Oct 14, 2011 at 10:32 AM, Rickard Öberg< >> > [email protected]> wrote: >> >> >> >> Well, I'd tend to agree with the author. Mixing persistence details with >> >> the domain model itself is really a bad idea. Infrastructure details >> >> should >> >> not pollute the domain logic as it does with the currently "suggested" >> >> usage >> >> of Neo4j. But I think both Spring Data Graph and the Qi4j usage model >> >> fixes >> >> this, as it allows you to keep many of those things outside of the domain >> >> code. >> >> >> >> /Rickard >> > >> > On Fri, Oct 14, 2011 at 11:45 AM, Tobias Ivarsson<tobias.ivarsson@ >> > neotechnology.com> wrote: >> > >> >> On Fri, Oct 14, 2011 at 11:21 AM, Rickard Öberg< >> >> [email protected]> wrote: >> >> >> >>> On 10/14/11 17:16 , Tobias Ivarsson wrote: >> >>> >> >>>> I was hoping for a bit more elaboration, of why it is a bad idea. >> >>>> >> >>>> Spring Data Neo4j operates mainly in the same way (at least it did when >> >>>> I was part of the design process), it just hides the details of it. >> >>>> >> >>>> The model we suggest is not to mix infrastructure details (nodes, >> >>>> relationships, traversals) with the domain logic. We suggest the domain >> >>>> logic be a separate layer, acting on domain data objects (defined as a >> >>>> set of interfaces). What we do suggest though is for those domain data >> >>>> objects to be implemented as wrappers of nodes and relationships. >> >>>> >> >>> That sounds like "transaction script+anemic domain model", which is an >> >>> anti-pattern as well. >> >> >> >> I'm guessing the anemic domain model is what you are pointing out as the >> >> anti-pattern. I can see how transaction scripts are and ADM usually come >> >> together though. >> >> >> >> References: >> >> >> >> http://martinfowler.com/eaaCatalog/transactionScript.html >> >> http://martinfowler.com/bliki/AnemicDomainModel.html >> >> >> >> >> >> >> >>> Domain logic should be in the domain objects, and so splitting them into >> >>> several layers confuse things more than it helps. >> >> >> >> I agree with you, SDN "solves" this, and does so well. >> >> >> >> >> >>> So is the bad part of it just the part of having the implementation of >> >>>> your domain data objects deal with the Neo4j API, instead of having DTOs >> >>>> and DAOs that you load from the database, operate on in memory, then >> >>>> store back to the db at explicit points? Or are there deeper issues than >> >>>> that? >> >>>> >> >>> It relates to testability (you should be able to test domain objects >> >>> without infrastructure), code cohesion (put domain logic in domain >> >>> objects), >> >>> and as the article author points out, separation of concerns in general. >> >> >> >> The testability aspect is interesting and important. I don't have enough >> >> SDN experience to know how it fares in that regard. >> >> >> >> "separation of concerns in general" - anything else to this? or would this >> >> (normally) be achieved when testability without infrastructure is >> >> achieved? >> >> >> > On Fri, Oct 14, 2011 at 11:49 AM, Rickard Öberg<rickard.oberg@ >> > neotechnology.com> wrote: >> > >> >> On 10/14/11 17:45 , Tobias Ivarsson wrote: >> >> >> >>> I'm guessing the anemic domain model is what you are pointing out as the >> >>> anti-pattern. I can see how transaction scripts are and ADM usually come >> >>> together though. >> >>> >> >> Yeah, it's when you use the two together (very common in Hibernate world >> >> as >> >> well) that you run into problems, if you do anything but cruddy stuff. >> >> >> >> >> >> The testability aspect is interesting and important. I don't have enough >> >>> SDN experience to know how it fares in that regard. >> >>> >> >>> "separation of concerns in general" - anything else to this? or would >> >>> this (normally) be achieved when testability without infrastructure is >> >>> achieved? >> >>> >> >> I suggest that you read up on SOLID: >> >> http://en.wikipedia.org/wiki/**SOLID_%28object-oriented_**design%29<http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29> >> >> >> >> And in particular SRP: >> >> http://en.wikipedia.org/wiki/**Single_responsibility_**principle<http://en.wikipedia.org/wiki/Single_responsibility_principle> >> >> >> >> Separating the domain objects from the infrastructure is a good start >> >> ("required but not enough"). >> >> >> >> >> >> /Rickard >> >> >> >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
