如果我选择 RavenDB，我会失去 SQL Server 的哪些优势？
如果我选择 RavenDB 作为相当标准的类似 CMS 的 Web 应用程序，那么与 SQL Server 相比我会失去什么？
编辑：标题中有一个词“好处”，这是一个有点争议的词。也许我应该说“可能性”或“特征”之类的东西，希望我所追求的是什么很清楚。
我想到了一些事情（但我是 RavenDB 的新手，所以这只是一些建议，有些可能是错误的，我希望有人能提供更完整和准确的列表）：
- 使用 ASP.NET 的快速但可定制的管理界面动态数据（有一些内置的 Silverlight 管理应用程序，但我很确定它不会取代我的情况下的成熟管理部分）
- 可能有一些查询功能？或者 Raven 索引可以替代我可能想到的几乎所有 SQL 查询吗？
- 实体框架集成（我知道有些人讨厌 EF，但我认为作为 EF 提供商意味着您可以轻松地将数据发布为 OData、使用 EF 代码优先等，对吧？）
Azure 部署(根据评论，不正确）- 无数的 SQL 查询/管理工具
如果有更完整/准确的列表，我们将不胜感激。
（注意：我并不是说我需要所有（或任何）这些，我只是想了解如果我选择 RavenDB，哪些内容将不可用。另外，请不要讨论 RavenDB 的优势，我知道其中，它们很容易从官方网站上理解。）
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.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能想看看 Ayende（RavenDB 创建者）最近发表的 2 篇博客文章，了解何时应该使用 RavenDB，何时不应该使用。
什么时候应该使用ravendb
什么时候不应该使用 ravendb
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
除了技术之外，你还应该考虑你的团队成员，因为 RavenDB 对于我们这些有 RDBMS 背景的人来说是一种思维上的调整。对于相关人员来说，这将是一种什么样的伸展运动？您的用户会期待报告吗？当您告诉他们您在为文档数据库创建索引时没有考虑回答他们想要回答的问题时，他们会怎么说？虽然在设计和实现域时您的工作效率会得到大幅提升，但文档数据库与 SQL 不同。
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.
ASP.NET MVC 从第二个版本开始支持基于 POCO 的脚手架。但这并不是那么快速又肮脏的解决方案。
您应该首先考虑您的疑问。 Raven DB 不是报告数据库。
您非常关注工具。 Code First 是使用文档数据库的方式。为什么需要 OData？ RavenDB 具有开箱即用的 REST API。
ASP.NET MVC supports scaffolding based on POCOs since second version. But it's not so quick'n'dirty solution.
You should to think about your queries first. Raven DB is not reporting database.
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.
WCF RIA 服务 (Silverlight)。
您需要完成所有 WCF 管道工作。
WCF RIA Services (Silverlight).
You'll need to do all that WCF plumbing work.