哪个面向文档的数据库比 Sql Server 具有更好的报告性能
我正在寻找一个面向文档的数据库来存储超过数百万张发票并具有快速的报告速度。
我找到了一些选项，例如 MongoDB、Ravendb、Couchdb，但我不知道与 Sql Server Xml 类型列相比性能失败的风险。
这个问题的来源是这里。
I'm looking for a document oriented database to store over millions of invoices with fast reporting speed.
I find some options such as MongoDB, Ravendb, Couchdb but I don't know the risk of performance failure vs. Sql Server Xml type column.
The source of this question is here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
快速报告是您想要在sql server 中做的事情。我不知道针对这种情况有什么好的 NoSQL 解决方案。
RavenDB 具有索引复制捆绑包，使您能够将索引复制到 SQL 表，以便您可以对它们执行一些高级报告。
Fast reporting is something that you want to do in sql server. I'm not aware of a good NoSQL solution for this scenario.
RavenDB has the index replication bundle that enables you to replicate an index to a sql table, so that you can do some advanced reports on them.
礼萨，
RavenDB 似乎很适合这里。这完全取决于您实际上所说的“报告”。
在 RavenDB 中，执行诸如“上个月有多少张发票”之类的事情很容易。
就像做“Northwind 欠我们多少钱？”之类的事情一样。
对于有动态报告需求（例如需要进行动态聚合）的特定情况，我们不建议使用 RavenDB 进行报告。
关于报告，您实际上想要做什么？？
除此之外，发票是 RavenDB 真正发挥作用的好地方，特别是考虑到这个问题的其他参数以及发票的动态性质。
Reza,
RavenDB seems like a good match here. It all depends on what you are actually calling "reporting".
Doing things like "how many invoices are there for last month" is easy in RavenDB.
As is doing things like "how much money does Northwind owe us?"
We don't recommend RavenDB for reporting for the specific case where you have dynamic reporting needs such as the need to do on the fly aggregation.
What is it that you are actually trying to do with regards to reporting?
That aside, invoices is a nice place where RavenDB truly shines, especially given the other parameters of this question with the dynamic nature of the invoices.
史诗般的失败已经在这里了。在大多数情况下（在您需要的所有情况下），发票是关系数据，因此地址链接、行项目、数字和价格都在表中，而不是 XML 数据类型。这就是“好吧，所以 - 你计划在麦当劳工作，而不是在我们团队工作？”关卡设计决策。
行项目和发票可能包含 XML 格式的附加数据（如时间表等），但如果您运行会计，则不会将其作为文档运行。
Epic fail already here. Invoices are relational data in most cases (in all you need) so address links, line items, numbers and prices are in tables, not XML data type. This is the "ok, so - you planned to wkr at McDonalds, not in our team?" level design decision.
What line items and invoices may have is additional data in XML (like timesheets etc.) but if you run accounting, you dont run it as documents.