.net - 使用选择的参数 : RavenDB vs SQL Server - performance, 可靠性和简单性

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




在为 Web 应用程序选择数据层时应该考虑哪些要点？

使用文档数据库而不是关系数据库，同时开发大而重的小项目，反之亦然，是否有更好的选择？

这些方法首选哪种数据库架构 - 如果我有没有太多关系的简单数据库，使用一种方法比另一种方法更好吗？

Answer 1

由于这个问题是邀请个人评论，这里是我的意见:

SQL Server 不是用于存储临时报告数据以外的任何内容的数据库。非常棒的是，即席报告、数据挖掘、实时关系发现 - 并且它是这些用途的最佳选择，因为早在 Codd 设计规则时，这就是它的设计目的(请参阅 Data Driven Conspiracy 了解更多信息)细节)

当然，您可以在关系数据库中存储其他类型的数据。例如，您可以将域状态序列化到 SQL Server 数据库并在以后检索该状态，但这是对关系系统的糟糕使用。太糟糕了，事实上，需要整层代码(所谓的“数据层”或 DAL)，数千行，才能使此类任务远程执行、可测试、可维护。

对于基于 SQL 的零售商来说，数十年来最大的信心技巧是让我们相信，除了在完全不同的数据结构之间进行实时转换之外，没有更好的方法来存储分层/文档数据。 DAL 和最新的 ORM 都被大肆宣传，但最终，这些只不过是编解码器，用于在不同的数据组织之间来回切换您的位 - 磁盘上的不同模式。

疯狂!

所以忘记所有关于原子性、一致性、隔离性和持久性的琐碎的、针尖上的天使论点。房间里的大象是，如果您使用的是 SQL Server 并且您不是一家在大量人群中动态挖掘数据立方体以进行隐藏推理的制药公司(是吗？)，那么您可能使用了错误的技术来存储您的数据.

另一方面，如果您是一个不起眼的应用程序开发人员 - 一个编码员，像我们大多数人一样，只是希望以一种并不意味着学习一套全新的意识形态和语法的方式序列化域状态，那么，为了善良为了，不要使用关系数据库。只是不要。

乌鸦数据库？我一直在使用它一段时间(通过 DB4O 和 CouchBase 发展而来)，我可以说它做到了它在 jar 头上所说的。它存储我的东西，并在我要求时还给我。我不必编写任何数据层，也不必使用第三方 ORM。我不必学习结构化查询语言，也不必为使全文搜索工作而添加额外的东西(RavenDB 基于 Lucene，所以一切都“正常工作”)。到现在为止还挺好。

但真的，只要它是手头的任务，易于编码，快速和高效，你使用什么就重要了吗？对于正常的应用程序开发来说，RavenDB 是所有这些东西，而 SQL Server 不是。这并不是说关系数据库不好——我们不要责怪受害者——我完全承认，对于某些专门的开发，你可能确实需要更多......异国情调的东西，比如关系数据存储。

但是，万一您仍然执着于残骸，您需要问自己这个问题:如果我们一直使用简单、快速、优雅的数据存储来满足我们作为应用程序开发人员的需求，然后我写了一篇意见文章敦促您采用 SQL Server 那么你很可能会 mock 我或同情我。有一件事是肯定的 - 您不会切换到 SQL Server。因此，我们证明了惯性本身就是使 SQL Server 成为主流的引导力。惯性和无知。惯性、无知和企业贪婪......