使用选择的参数：RavenDB 与 SQL Server - 性能、可靠性和简单性 [关闭]

Posted 2023-03-30

【中文标题】使用选择的参数：RavenDB 与 SQL Server - 性能、可靠性和简单性 [关闭]

【英文标题】：Arguments for usage choice: RavenDB vs SQL Server - performance, reliability and simplicity [closed]

【发布时间】：2012-05-09 10:22:05

【问题描述】：

在为 Web 应用程序选择数据层时应考虑哪些方面？

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

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

【参考方案1】：

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

SQL Server 不是用于存储临时报告数据以外的任何内容的数据库。非常棒的是，即席报告、数据挖掘、实时关系发现——它最适合这些用途，因为早在 Codd 设计规则时，这就是它的设计目的（参见Data Driven Conspiracy 了解更多信息）详情）

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

几十年来，基于 SQL 的零售商一直在说服我们，除了在完全不同的数据结构之间进行实时转换之外，没有更好的方法来存储分层/文档数据。 DAL 和最新的 ORM 都被吹捧过，但归根结底，这些只不过是用于在不同数据组织之间来回传输数据的编解码器 - 磁盘上的不同模式。

疯狂！

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

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

RavenDB？我已经使用了一段时间（通过 DB4O 和 CouchBase 发展），我可以说它确实做到了它在锡上所说的那样。它存储我的东西并在我要求时将其归还给我。我不必编写任何数据层，也不必使用第三方 ORM。我不必学习结构化查询语言，也不必附加额外的东西来使全文搜索工作（RavenDB 基于 Lucene，所以一切都“正常工作”）。到目前为止一切顺利。

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

但以防万一您仍然固执己见，您需要问自己这个问题：如果我们一直使用简单、快速、优雅的数据存储，这些数据存储非常适合我们作为应用程序开发人员的需求，然后我写了一篇评论文章敦促您采用 SQL Server，那么您很可能会嘲笑我或同情我。有一件事是肯定的——你不会切换到 SQL Server。因此，我们证明惯性本身就是使 SQL Server 成为主流的指导力量。惰性和无知。惰性、无知和企业贪婪....

【讨论】：

嘘，问题已结束。毕竟我的打字也是如此。

只是想说-感谢您撰写此回复。我发现它很有趣且内容丰富。

@biofractal：你用的是商业版的 RavenDB 还是免费版的？我可以免费将 RavenDB 用于我的社交网站吗？免费版有什么限制吗？

@user636525 这里是 RavenDBs licensing terms

谢谢！我问了他们，​​他们告诉我我必须付钱，所以我会选择 MongoDB :)