Ayende @ Rahien

Ayende Rahien commented on As the user’s put it: Insight into the RavenDB design mindset

Fri, 27 Apr 2012 23:21:55 GMT

Karep, Indexes are very easy to create, and RavenDB can build them in the background so even on very busy sites, there isn't any downside (online index building). In short, you just deploy your index along with your new code, and you are pretty much done.

Rafal commented on As the user’s put it: Insight into the RavenDB design mindset

Fri, 27 Apr 2012 12:02:32 GMT

Jean: why not? For 90% of applications any database will do.

Jean commented on As the user’s put it: Insight into the RavenDB design mindset

Fri, 27 Apr 2012 08:21:37 GMT

Before 2012: Use RavenDB for X,Y,Z scenarios. After 2012: Use RavenDB for everything! You are quoting someone who has a CMS background and where a document database fits perfectly. However not everyone is building a CMS application.

Shaddix commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 17:40:12 GMT

Not to be misunderstood: i'm not arguing against Raven at all, moreover, I wish I had a chance to try it on some real project :) But well said, technology should make simple things simple, and hard things possible. Simple things (it seems, what I'm doing now is all simple) are a bit harder with Raven against NH (and not only because of learning curve). It's hard to discuss complex scenarios, because everyone has his own story in mind, but map-reduce looks a lot like stored procedures to me, with the same disadvantage, that I get some sort of DTO/ViewModel from it, and not a clean repeatable Domain class. Yes, there's no other way in really complex stories with a lot of data, but with my current experience in Raven, Map-Reduces are very common even in relatively simple cases.

Rasmus Schultz commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 12:18:13 GMT

Yeah, in my experience, NH is only simple so long as what you're doing is simple. For really complex applications, it's the illusion of simplicity. Too often, it turns out your O/R mapping is based on the structure of the data itself, rather than on expected data-access patterns. "Just do a load" covers maybe about 20% of the cases on the project I've been working on for the past 2 years - the other 80% is painstaking uphill battles with HQL or the Criteria API to try to force it to write the exact query I want. For comparison, I would say, NH is ultimately flexible in terms of query building and data-access patterns - that flexibility is great for a data-analyst writing one-off SQL queries, mining data for information that the client has asked for. But it is very rarely necessary in software, and it comes at the price of very high complexity. In contrast, with RavenDB, you define the data-access patterns required by your software, in the form of indexes. Of course, if you're using NH and doing a good job, you're probably also defining the data-access patterns required by your software, perhaps in the form of services or factory-classes. The difference is, those factory-classes are usually much more expensive to build, to maintain, as well as to run...

Rafal commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 11:05:45 GMT

The most striking difference between relational and document database for me was the discovery of multi-valued (array) fields and how efficiently you can query them with Lucene compared to SQL (in sql you have to use many to many relationship and one or two level deep nested query just to do a simple 'in' on a multi-valued field)

Scooletz commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 11:03:22 GMT

@Karep, indexes are created on the fly, used multiple times they becoming persistent. If your reports need any sofisticated aggregations, you can always export your data to a relational db and use good old fashioned SQL

Karep commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 08:51:05 GMT

One think I don't understand with RavenDB is that from what I understand you have to create indexes in order to be able to search. But what if one day client asks for report you didn't expect and did not create index for? It happens every month to us. But maybe that's my misunderstanding of RavenDb?

Shaddix commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 08:18:31 GMT

> "just do a Load" in NHibernate, that is just not true. Why it isn't? May be things I'm dealing with are too simple, but it works pretty good. Sure, there are complex parts, where "only one load" is not enough at all, but well, I'm taking about another 50% cases :) It's not that optimal, but if it's not a high-load service then it's worth savings on developer's time. >you are likely still trying to model things in a relational way let's take a simple example of User entity. It should be a separate entity and I'd like to "join" it in all the places. Sure I can denormalize "just login" and live with it, but it's not that comfortable as with joining, where it's easy for me to output birthdate, lastvisit, etc. in any place where I/UI designer want.

Ayende Rahien commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 07:50:19 GMT

Shaddix, Um... no. Take a look at modeling concerns in relational databases as well, and they are full of the same scenarios as well. What are you doing impact how you are storing the data. The major problem is that in relational databases,you often have no choice in how to model the data, because of the schema limitations. And as for "just do a Load" in NHibernate, that is just not true. I have been doing NHibernate for close to a decade now, and I have been involved in dozens if not hundreds of projects. That is _much_ more complex than that. As for creating ViewModel classes, you are likely still trying to model things in a relational way, which is why you are getting this issue

Shaddix commented on As the user’s put it: Insight into the RavenDB design mindset

Thu, 26 Apr 2012 06:55:01 GMT

And from the otherside that's really a problem. You design Raven-"schema" for specific scenarious. Answering on some questions in google-group you always ask "what exactly you're trying to do", and that's correct question, because the answer differs depending on that. But well, you've designed something and another day requirements change and your existing schema is already not "the best solution" for that. Isn't that happening? Relational world is good for the simple design rules, it's basically table per entity and that's it. And it suits nearly all your needs in all scenarious (but yes, fulltext search is way simpler in Raven :)) And domain model usage is simpler with NH. It's just .Load(id) with batch-size enabled, and it covers 70% of use-cases without additional queries/classes. Working with relations in Raven always make me create new "ViewModel" classes to hold entities and it's relations.. that's adding noise to the code :)