[…] implementing Auto Save in the RDBMS system could be a problem because of multiple reasons:

• The schema and overall logic changes to save versioned data in the RDBMS system will be non-trivial
• There might be validation checks that fail because users kept didn’t fill out some fields at that point.
• Making periodic (30 second) transactional updates to any live system is not good for overall performance.

A work around would be saving your Object Model to RavenDB directly and if user visits the document after a time out, load both Transactional Data and Object data, compare the timestamp and use the freshest set of data.

By far the best document database usecase I have read about in quite a while.

Original title and link: Implementing Auto Saves Using RavenDB: NoSQL Tutorials (NoSQL database©myNoSQL)

via: http://www.dotnetcurry.com/ShowArticle.aspx?ID=784

RavenDB still has a weakness that prevents it from becoming the instant choice of all green-field (a project starting fresh) ASP.NET MVC web projects. Most reporting solutions today work best off RDBMS systems and NoSQL databases are just getting their feet wet with respect to Reporting system connectivity.

So if you are building a system that doesn’t require traditional reporting systems to hook in and retrieve data, RavenDB is the perfect choice. More often that not, that’s not the case (specially Line of Business applications) and hence we tend to fallback on SQL Server/MySQL/Oracle etc.

Leaving aside the (very) short bullet point definition of RavenDB, the conclusion sounds confusing. It makes me wonder if the majority of ASP.NET projects are mostly about reporting.

Original title and link: Introducing RavenDB for ASP.NET Developers: NoSQL Tutorials (NoSQL database©myNoSQL)

via: http://www.devcurry.com/2012/01/hello-ravendb-introducing-ravendb-for.html

Daniel Lang presents 6 solutions for dealing with relations in RavenDB:

If you’re coming from the sql world, chances are you will be confused by the lack of relations in document databases. However, if you’re running RavenDB you’ve got plenty of options to address this trade-off. I personally cannot think of any situation where I’d wish back SQLServer because of this (there could be other reasons).

Two not recommended:

• go to the database twice
• include one document inside the other

Two RavenDB specific solutions:

• implement a read trigger to do server-side joins
• implement a custom responder

Two recommended solutions:

• use the .Include<T>() method
• denormalize your references

Couple of comments:

• the difference between “include one document inside the other” and “denormalize your references” is very subtle—the latter suggests including only the information needed for the presentation layer.
• I think one should consider both “include one document inside the other” and “denormalize your references” and choose one of them depending on the chances of the embedded documents being updated often vs the chances of having the presentation layer changing often
• except RavenDB, all other document databases seem to offer only two options: “go to the database twice” and “denormalize your references”
• when Redis will release its version embedding server-side Lua, that could be used as a form of stored procedure

Original title and link: 6 Ways to Handle Relations in RavenDB and Document Databases (NoSQL database©myNoSQL)

via: http://daniellang.net/how-to-handle-relations-in-ravendb/

Given that this is something new and an open source project you may find yourself searching for help and more guidelines. 

Summarized:

• Use RavenDB REST interface with curl
• RavenDB operations are logged on the console app
• RavenDB indexing is a background process so there is a gap between a write and index update
• RavenDB can run in embedded mode

I bet Ayende has more tricks up his sleeves so hopefully he’ll jump in to share.

Original title and link: RavenDB: Debugging and Troubleshooting (NoSQL database©myNoSQL)

via: http://activeengine.wordpress.com/2011/12/15/approvaflow-a-quick-primer-on-ravendb/

Ayende, the creator of RavenDB:

Typically, it isn’t the only database in the project. In brown field projects, we usually see RavenDB brought in to serve as a persistent view model store for the critical pages, data is replicated to RavenDB from the main database and then read directly from RavenDB in order to process the perf critical pages. For green field projects, we usually see RavenDB used as the primary application database, most or all of the data resides inside RavenDB. In some cases, there is also an additional reporting database as well.

So the quick answer, and the one we are following, is that RavenDB is imminently suitable for OLTP applications, and can be used with great success as a persistent view model cache.

You’d be right say that this is an answer that could be used for most of the NoSQL databases. Looking back at their history, most of the NoSQL databases have started as ways to address problems that people in the field have been having with relational databases. Thus NoSQL databases were mostly used together or at least in the same environment with the relational databases or other storage solutions. Also considering NoSQL databases are an evolving technology, not everyone dropped their existing data stores and started to use them.

Adding NoSQL technologies to existing stacks is the leanest adoption path and the one that minimizes risks. Not to mention that this is the way to accumulate experience with them without putting at risk your business.

Now going back to RavenDB, there are a few titillating features that might arouse your curiosity.

Original title and link: When to Use RavenDB? (NoSQL database©myNoSQL)

via: http://ayende.com/blog/136196/when-should-you-use-ravendb

Julie Lerman in an article offering an overview of 3 document databases (CouchDB, MongoDB, RavenDB):

In my research, I’ve heard a MongoDB expert say that the product’s primary concern is performance. A CouchDB expert pointed to simplicity and reliability (“we want to be the Honda Accord of databases”). And Ayende Rahien, creator of RavenDB, said RavenDB aims for “fast writes, fast reads and world peace.” Each of these document databases has even more to offer than what these sound bites suggest.

With the exception of a few twists (which I’ll point out in this article), these databases provide their data most commonly through HTTP, store their data as JavaScript Object Notation (JSON) documents and provide APIs in multiple languages. The overall concerns are simplicity, speed and scalability. Equally important is that all three are open source projects.

Original title and link: What the Heck Are Document Databases? (NoSQL database©myNoSQL)

via: http://msdn.microsoft.com/en-us/magazine/hh547103.aspx

Niklas Lundberg summarizes the advantages of using the native .NET document database RavenDB:

As a .NET developer the document database RavenDB is attractive since it provides us with a built-in .NET API, HTTP API and many of the features a NoSQL database can offer. In a web environment the HTTP API is useful because it could eliminate the need for a middle tier for simple scenarios where you don’t need all the features the server side could offer. In RavenDB all documents are stored as JSON and its input and output is also JSON.

And under the covers, RavenDB has a couple more niceties:

• RavenDB bundles: replication, versioning, authorization, spatial queries
• Multi-Document Transactions in RavenDB vs Other NoSQL Databases
• RavenDB and attachments
• RavenDB Filtered Replication
• RavenDB and HTTP Caching
• RavenDB to add auto sharding

Original title and link: Why RavenDB for .NET Development? (NoSQL database©myNoSQL)

via: http://blog.jayway.com/2011/09/22/nosql-with-ravendb/