9

If I choose RavenDB for a fairly standard CMS-like web application, what do I lose compared to SQL Server?

EDIT: There is a word "benefits" in the title which is a little controversial term. Maybe I should have said something like "possibilities" or "features", hope it's clear what I'm after.

A few things that come to mind (but I'm new to RavenDB so this is just a few suggestions, some may be wrong, I hope someone would provide a more complete and accurate list):

  • Quick but customizable administrative interface using ASP.NET Dynamic Data (there is some built-in Silverlight admin application but I'm quite sure that it wouldn't replace a full-fledged admin section in my case)
  • Possibly some querying capabilities? Or can Raven indexes replace virtually every SQL query I might think of?
  • Entity Framework integration (I know some people hate EF but I think that being an EF provider means that you can easily publish the data as OData, use EF code-first etc., right?)
  • Azure deployment (not true according to comments)
  • Myriad of SQL querying / management tools

A more complete / accurate list would be greatly appreciated.

(Note: I'm not saying that I will need all (or any) of those, I'd just like to understand what's going to be unavailable if I choose RavenDB. Also, please don't discuss RavenDB strengths, I am aware of them and they are easily digestible from the official website.)

Borek Bernard
  • 50,745
  • 59
  • 165
  • 240

4 Answers4

3

You may want to look @ these 2 recent blog posts by Ayende (RavenDB creator) on when you should use RavenDB and when you shouldn't.

When should you use ravendb

When should you not use ravendb

scartag
  • 17,548
  • 3
  • 48
  • 52
  • 2
    I've seen those posts. However, I'd rather gather a list of things that will not be available when I choose RavenDB with the hope that I will then be able to make a good decision myself. – Borek Bernard Nov 24 '11 at 09:06
1

Beyond the technology, you should consider your team members as RavenDB is an adjustment in thinking for those of us who have backgrounds in RDBMS. What type of stretch will this be for those involved? Will your users expect reports and what will the say when you tell them that you did not consider answering the questions that they want answered when you create the indexes for the document database? While you get a big boost in productivity when designing and implementing your domain, document databases are different than SQL.

David Robbins
  • 9,996
  • 7
  • 51
  • 82
  • Certainly, those are all good points, however, at this point, I'd just like to gather a list of things that will not be technically available with RavenDB. That would be a good starting point. – Borek Bernard Nov 24 '11 at 09:08
1

Quick but customizable administrative interface using ASP.NET Dynamic Data (there is some built-in Silverlight admin application but I'm quite sure that it wouldn't replace a full-fledged admin section in my case)

ASP.NET MVC supports scaffolding based on POCOs since second version. But it's not so quick'n'dirty solution.

Possibly some querying capabilities? Or can Raven indexes replace virtually every SQL query I might think of?

You should to think about your queries first. Raven DB is not reporting database.

Entity Framework integration (I know some people hate EF but I think that being an EF provider means that you can easily publish the data as OData, use EF code-first etc., right?)

You are so focused on tools. Code First is the way how you work with document databases. Why you need OData? RavenDB has REST API out of the box.

Aleš Roubíček
  • 5,198
  • 27
  • 29
0

WCF RIA Services (Silverlight). You'll need to do all that WCF plumbing work.

Ashok Guduru
  • 1