Here's my small contribution to this. First of all I wanted to say that I totally agree with Thad when he says: *"Folks just need better much more detailed Domain Model examples than what is available, that would help incredibly so, since many folks have a complex Domain Model to begin with..."* The matrix sample is cool but not very useful when you have to tackle with much more complex domains.
It's already been a while since the last time I looked for information about how to build your domain model with Neo4j but I just did a quick google search and found this: http://wiki.neo4j.org/content/Guidelines_for_Building_a_Neo4j_Application which guess is the 'official' documentation for it right? *(please correct me if I'm wrong)* * * There I'm missing a lot of information plus real-world examples in the sub-sections of Structuring your graph: - *Keep your graph connected --> **What do you exactly mean with this?* - *Use reference and subreference nodes to organize entry points* --> (In principle I don't even agree with this. Well, I do in theory and it actually is how I implemented things in the beginning. However in my case, where I'm dealing with huge amounts of relationships, reference and subreference nodes become supernodes which in turn are a very problematic bottleneck in most traversals;* (this is due to the lack of a natively implemented system for discerning between relationships with different types, I opened this issue about this here: https://github.com/neo4j/community/issues/19 ).*While this is solved, I'm always tempted/forced to start using indexes instead of relationships, but then I wonder how different things are in the end compared to other not graph-based DB systems !?? - Prefer relationships to properties when your whiteboard tells you to --> I agree with this but still miss at least a short explanation of what this means. - *Use relationships types appropiately -->* I know maybe it's not the better place to say this but I never understood why there're mandatory relationships types but not node types !?* (I'm in favor of mandatory node types by the way)* - * Use an indexing service to find nodes by property values * * * Summing up I'd like to emphasize the lack of information/documentation in general for cases which are not the typical small DB whose domain model can be in principle easily designed with just a bit of common sense. Nonetheless this lack of info can be easily covered by the great support you guys provide here; *(still I think it's too bad having this (IMHO) big gap between the great quality of support you provide in this user-list and that of the 'static' documentation present in the wiki.)* With all this having been said, I still find Neo4j a very promising DB in the near future and I'm really happy to use it in a lot of different projects/use-cases; however I think the way for it to get better each day is not keeping saying how cool it is but actually pointing at the weak spots it may have. Cheers, Pablo On Fri, Oct 14, 2011 at 4:14 PM, Thad Guidry <[email protected]> wrote: > I would suggest breaking down his statement further and fill in the blanks > to gain even better insight into his conjecture. > > "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." > > > "it's" - Neo4j > > "to wrap objects around IT" - what is the IT that he is referring to ? > > "you have to have THEM explicitly incorporate THEIR node class" - what is > THEM / THEIR really mean for Neo4j here ? > > "law of separation of concerns" - what and where are we JOINING that should > be SEPARATING , is it only the Domain objects ? > > > From outside looking in, I have seen others not complete their Domain Model > as needed with Neo4j, and also make it entirely TOO SIMPLE. Why ? Because > they might be new to graph databases, or their Domain Model really IS NOT > complete yet and they need help from others to assist with putting together > an elegant Domain Model to begin with. Being able to easily wire up a > Domain Model is the primary reason they were attracted to graph databases > in > the first place !... to build it out without resorting to defining a rigid > schema (a SQL table mantra). But many need help in contorting their Domain > Model over time. To me, Neo4j is already wide open enough to handle that > contortion and the beauty of Neo4j & graph databases in general. > > Folks just need better much more detailed Domain Model examples than what > is > available, that would help incredibly so, since many folks have a complex > Domain Model to begin with (they just do not realize it yet) and they are > hoping Neo4j will help them quickly wire it up, stretch it out when needed, > and analyze the hell out of it when the time comes, and stretch it out even > more as they continue to fill it up and expand their Domain Model. A > bottom > up approach (and I mean really BOTTOM) is the best practice, but it does > take thought and research in finding where that generic bottom is at. A > "Friend" - what is a Friend, what attributes does a Friend have ? Which > ones > do I care about now and can worry about later ? A "Stock Issuing Company", > do I need to think of my relationships first for those, or should I start > with attributes ? Will those attributes be shared with others ? Do I care > about it now at this early beginning of my Domain Model, or can I wait on > this ? Should I start with attributes (properties) always, and leave > relationships alone until the very end, when I build a Domain Model ? (the > answer to that last question is YES, because Neo4j actually DOES allow you > to) > > > 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. > > > > Your main model IS NOT Neo4j. That is your main database that "holds" your > Domain Model. And if Neo4j is not really doing this from top to bottom, > then I would agree with Richard that the Neo4j infrastructure is not in the > best place right now and might need more work. > > -- > -Thad > http://www.freebase.com/view/en/thad_guidry > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Pablo Pareja Tobes My site http://about.me/pablopareja LinkedIn http://www.linkedin.com/in/pabloparejatobes Twitter http://www.twitter.com/pablopareja Creator of Bio4j --> http://www.bio4j.com http://www.ohnosequences.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
