我可以使用 RavenDB (NoSQL) 还是应该使用 MySQL(RDBMS)？
我开始使用 ASP.NET MVC 3 通用管理系统（项目管理是第一个组件）。现在我已经阅读了一些关于 RavenDB 的文章，听起来很有趣。我最喜欢它的事情之一是我不需要 ORM 上的任何类型来处理来自数据库的数据。这将使我的代码更加干净和快速。然而，由于过去 6 年多以来我一直在专门使用 MySQL，因此我倾向于认为与我的数据密切相关。有一些事情似乎 NoSQL 不适合做。我想把这些东西扔到那里，也许这些问题可以在 NoSQL 解决方案中处理，我只是觉得太相关了（话又说回来，也许这个项目应该用 MySQL 来完成）。这些是我正在考虑的问题：
唯一标识符：我希望能够为很多东西拥有唯一标识符。对于像项目这样的东西，名称应该是唯一的并且可以使用它，但是当涉及到项目下的任务时，标题可能不是唯一的，这就是我将使用 quto-increment 字段的地方，但我可以在 RavenDB 中做到这一点（据我所知）
链接：用于状态和类型等字段时，我只会使用带有外键的链接。现在，对于一对多关系，我可以只使用文本，而不是尝试链接外键（NoSQL 中没有），而是使用多对多链接，这是一个问题。例如，我打算有一个标签系统（就像这里一样），其中大多数项目可以附加一到多个标签，然后我可以在这些标签上执行搜索项目。有没有办法在 NoSQL 中做到这一点？
RDBMS 真的是完成这项工作的最佳工具吗？或者我只是没有正确地思考“NoSQL”方式，而我可以使用 NoSQL (RavenDB) 来完成此任务？
I am starting on a ASP.NET MVC 3 General Management System (Project Management being the first component). Now I have been reading up a bit on RavenDB and it sounds pretty interesting. One of the biggest things that I like about it is the fact I would not need any type on ORM to handle the data from the DB. This will make my code a lot cleaner and quicker. However coming from a background working exclusively with MySQL for the past 6+ years, I tend to think very relationally with my data. There are a few things that seems like NoSQL would not be good for. I want to throw these things out there and maybe these issues can be handle in a NoSQL solution and I am just think too relationally (then again, maybe this project should be done with MySQL). These are the issues I am thinking of:
Unique Idenifiers: I am going to want to be able to have unique identifiers for a lot of things. For stuff like projects, the name should be unique and could use that however when it come to tasks under a project, the title may not be unique and this is where I would use a quto-increment field but I can do that in RavenDB (from what I can tell)
Linking: Using for fields like status and type I would just use a linking with a foreign key. Now for one-to-many relationships, I can just use the text instead of trying to link a foreign key (which you don't have in NoSQL) but with many-to-many linking, that because a problem. For example, I intend to have a tagging system (like on here) where most items can have 1 to many tags attached to it and then I can perform searches on those tag for the items. Is there a way to do this in NoSQL?
Is a RDBMS really the best tool for the job here or am I just not properly think the "NoSQL" way and I can accomplish this with NoSQL (RavenDB)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我知道这是一个旧帖子。也许这些文档最初编写时并不那么好。但供参考，以防其他错误：
Raven 默认带有 HiLo 文档 ID 生成策略。在不自己指定 id 的情况下存储新文档将获得一个自动递增的 id，例如“projects/1”、“projects/2”等。阅读更多 此处。
有关处理文档关系的不同方法的最佳指南位于此处< /a> 在文档中。对于您所描述的情况，您实际上根本不需要单独的文档。您可以简单地将标签名称的字符串数组嵌入到每个项目中。文档不是平面的，它们可以结构化。是的，您仍然可以查询它们。
希望您自最初的帖子以来已经发现了这一点。
I know this is an old post. Perhaps the docs weren't as good when originally written. But for reference in case other stumble here:
Raven comes with a HiLo document id generation strategy by default. Storing a new document without specifying an id yourself will get an auto incrementing id such as "projects/1", "projects/2", etc. Read more here.
The best guidance on the different ways to handle document relationships is here in the documentation. For the situation you described, you don't really need a separate document at all. You can simply embed a string array of tag names into each item. Documents are not flat, they can be structured. And yes, you can still query on them.
Hopefully you've discovered this on your own since the original post.
Ayende 写了一篇文章 “在 RavenDB 中建模参考数据”，其中回答了您的一些问题重新链接。您将拥有参考文档和其他文档之间的数据副本，并且对于文档数据库来说，冗余是“可以”的。您仍然可以根据您存储的 ID 或文本构建索引或查询。
我更喜欢将 SQL 用于事务系统，例如需要执行即席查询的应收帐款应用程序。使用文档数据库，您确实需要考虑如何获取数据并预先构建索引来回答这些问题。 RavenDB 还有一个动态索引功能，可以学习并缓存在数据库中触发的查询。
对于大多数项目都是任务的项目管理，我认为 RavenDB 可以满足您的需求。
Ayende wrote a post "Modeling reference data in RavenDB" which answers some of your questions re Linking. You will have copies of the data between the reference document and your other documents and that redundancy is "ok" for document databases. You can still build indexes or query based on the on either Id or text that you store.
I would favor SQL for a transaction system such as Accounts Receivable application where you need to perform ad hoc queries. With document database you really need to think through how you will be fetching your data and build indexes up front to answers those questions. With RavenDB there is also a dynamic indexing function that learns from and caches the queries that are fired at the database.
For project management where the majority of items would be tasks I would think a RavenDB would fit your needs.