[Neo4j] Article: "The Coming SQL Collapse"

Tobias Ivarsson tobias.ivarsson at neotechnology.com
Fri Oct 14 14:48:37 CEST 2011


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 <
tobias.ivarsson at neotechnology.com> 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 <tobias.ivarsson at neotechnology.com>
>

On Fri, Oct 14, 2011 at 10:32 AM, Rickard Öberg <
rickard.oberg at neotechnology.com> 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 <
> rickard.oberg at neotechnology.com> 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
>
-- 
Tobias Ivarsson <tobias.ivarsson at neotechnology.com>
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857 (Swe); +1 650 450 3806 (US)


More information about the User mailing list