NoSql/Raven DB 实施最佳实践
我正在调查一个新项目，该项目将是一个社交网络风格的网站。我正在阅读 RavenDb，我喜欢它的许多功能的外观。我没有读过太多关于 nosql 的文章，但我想知道是否有一个最适合它的利基市场，而老式的 sql 仍然是其他东西的最佳选择。
我认为权限插件对于社交网络风格的网站来说是理想的选择 - 但它真的会在数据库受到重击的环境中执行吗 - 或者它是否针对更多报告风格的系统进行了优化，可以保留将新的数据结构放入数据库并报告这些结构。
我渴望使用正确的工具来完成这项工作 - 我将使用 MVC3、Windsor + Nhibernate+Sql 服务器或 RavenDb。
我应该坚持使用老式的 sql 还是使用新的 sql：ravendb？
I'm investigating a new project which will be a social networking style site. I'm reading up on RavenDb and I like the look of a lot of its features. I've not read up on nosql all that much but I'm wondering if there's a niche it fits best with and old school sql is still the best choice for other stuff.
I'm thinking that the permissions plug in would be ideal for a social net style site - but will it really perform in an environment where the database will be getting hammered - or is it optimised for a more reporting style system where it's possible to keep throwing new data structures at the database and report on those structures.
I'm eager to use the right tool for the job - I'll be using MVC3, Windsor + either Nhibernate+Sql server or RavenDb.
Should I stick with the old school sql or go with the new kid on the block: ravendb?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题可能非常接近于主观（尽管实际上并非如此），您谈论 NoSQL 就好像它只是一件事，但事实并非如此。
你有
他们每个人都试图通过不同的方式解决不同的问题，而您是否会使用其中的一个而不是传统的关系存储是
最终，对于主要的 单个系统的数据存储、文档数据库或关系存储可能是您想要的，尽管对于系统的不同部分，您很可能最终会使用图形数据库（用于计算邻居等）或密钥/价值存储（就像 Facebook 对收件箱消息所做的那样）。
与关系存储相比，选择文档存储作为主存储的主要好处是，您不必担心尝试将对象映射到表集合中，并且这样做所涉及的配置开销更少。
另一个缺点/优点是你必须学习新东西并在此过程中犯错误。
那么我的回答是否直接？
您更喜欢使用哪一个？这些天我可能会选择 Raven，因为我知道我可以将数据转储到关系存储中以用于报告目的，并且可能对系统的其他部分也这样做，并且无需使用即可获得自由文本搜索和快速写入/快速读取通过定义单独的读/写存储的努力是一个整体的胜利。
但这就是我，而且我有偏见。
This question can get very close to being subjective (even though it's really not), you're talking about NoSQL as if it is just one thing, and that is not the case.
You have
Each of them attempts to solve a different problem via different means, and whether you'd use one of them over a traditional relational store is
At the end of the day, for the primary data-storage for a single system, a document database or relational store is probably what you want, although for different parts of your system you may well end up utilising a graph database (For calculating neighbours etc), or a key/value store (like Facebook does/did for inbox messages).
The main benefit of choosing a document store as your primary store over that of a relational one, is that you haven't got to worry about trying to map your objects into a collection of tables, and there is less configuration overhead involved in doing so.
The other downside/upside would be that you have to learn something new and make mistakes along the way.
So my answer if I am going to be direct?
Which do you prefer to use? These days I'd probably just go for Raven, knowing I can dump data into a relational store for reporting purposes and probably do likewise for other parts of my system, and getting free-text search and fastish-writes/fast-reads without going through the effort of defining separate read/write stores is an overall win.
But that's me, and I am biased.