Si je choisis RavenDB, quels sont les avantages de SQL Server que je perds?

Si je choisis RavenDB pour une application web de type CMS assez standard, qu'est-ce que je perds par rapport à SQL Server?

EDIT : Il y a un mot "avantages" dans le titre qui est un terme un peu controversé. Peut-être que j'aurais dû dire quelque chose comme "possibilités" ou "caractéristiques", j'espère que c'est clair ce que je veux.

Quelques choses qui me viennent à l'esprit (mais je suis nouveau à RavenDB donc ce n'est que quelques suggestions, certaines peuvent être fausses, j'espère que quelqu'un fournira une list plus complète et plus précise):

  • Interface administrative rapide mais personnalisable utilisant ASP.NET Dynamic Data (il existe une application d'administration Silverlight embeddede mais je suis certain qu'elle ne replaceait pas une section d'administration à part entière dans mon cas)
  • Peut-être quelques capacités d'interrogation? Ou les index Raven peuvent-ils replace pratiquement toutes les requêtes SQL auxquelles je pourrais penser?
  • Entity Framework integration (Je sais que certaines personnes détestent EF mais je pense que le fait d'être un fournisseur EF signifie que vous pouvez facilement publier datatables en tant qu'OData, utiliser le code EF d'abord etc., n'est-ce pas?)
  • Déploiement Azure (pas vrai selon les commentaires)
  • Une myriade d'outils d'interrogation / gestion SQL

Une list plus complète / précise serait grandement appréciée.

(Note: Je ne dis pas que j'aurai besoin de tout (ou de tout) de ceux-ci, je voudrais juste comprendre ce qui ne sera pas disponible si je choisis RavenDB.En outre, s'il vous plaît ne pas discuter des forces de RavenDB, je suis conscient d'entre eux et ils sont facilement digestibles sur le site officiel.)

    Vous pouvez regarder @ ces 2 articles de blog récents par Ayende (créateur RavenDB) sur quand vous devriez utiliser RavenDB et quand vous ne devriez pas.

    Quand devriez-vous utiliser ravendb

    Quand ne devriez-vous pas utiliser ravendb

    Au-delà de la technologie, vous devriez considérer les membres de votre équipe comme RavenDB est un ajustement de la pensée pour ceux d'entre nous qui ont des antécédents dans le SGBDR. Quel type d'étirement sera-ce pour ceux qui sont impliqués? Vos users s'attendent-ils à recevoir des rapports et que dira-t-on lorsque vous leur dites que vous n'avez pas envisagé de répondre aux questions auxquelles ils veulent répondre lorsque vous créez les index pour la database de documents? Tandis que la productivité et la mise en œuvre de votre domaine augmentent considérablement, les bases de données de documents sont différentes de SQL.

    Interface administrative rapide mais personnalisable utilisant ASP.NET Dynamic Data (il existe une application d'administration Silverlight embeddede mais je suis certain qu'elle ne replaceait pas une section d'administration à part entière dans mon cas)

    ASP.NET MVC prend en charge l'échafaudage basé sur POCOs depuis la deuxième version. Mais ce n'est pas une solution si rapide et si désagréable.

    Peut-être quelques capacités d'interrogation? Ou les index Raven peuvent-ils replace pratiquement toutes les requêtes SQL auxquelles je pourrais penser?

    Vous devriez d'abord penser à vos requêtes. Raven DB ne rapporte pas de database.

    Entity Framework integration (Je sais que certaines personnes détestent EF mais je pense que le fait d'être un fournisseur EF signifie que vous pouvez facilement publier datatables en tant qu'OData, utiliser le code EF d'abord etc., n'est-ce pas?)

    Vous êtes tellement concentré sur les outils. Code First est la façon dont vous travaillez avec les bases de documents. Pourquoi avez-vous besoin d'OData? RavenDB a l'API REST sortie de la boîte.

    WCF RIA Services (Silverlight). Vous devrez faire tout ce travail de plomberie WCF.