使用选择的参数:RavenDB与SQL Server - 性能,可靠性和简单性

Question

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

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

对于这些方法,首选哪种数据库体系结构 - 如果我有简单的数据库没有太多关系,那么使用一种方法比另一种方法更好吗？

Answer 1

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

SQL Server不是用于存储除临时报告数据之外的任何内容的数据库.它非常出色,特别报告,数据挖掘,实时关系发现 - 以及它对这些用途的最佳选择,因为当Codd设计规则时,就是它的设计目标(参见数据驱动的阴谋以获取更多信息)细节)

当然,您可以在关系数据库中存储其他类型的数据.例如,您可以将域状态序列化为SQL Server数据库并在以后检索该状态,但这是对关系系统的可怕使用.事实上,如此糟糕,整个代码层(所谓的"数据层"或DAL),数千行,都需要使这种任务远程可执行,可测试,可维护.

对于基于SQL的零售商而言,这种伟大的,长达数十年的信心技巧已经让我们相信,除了根本不同的数据结构之外,没有更好的方法来存储分层/文档数据.DAL和最新的ORM都被大肆吹嘘,但最后,这些只不过是编解码器,可以在不同的数据组织之间来回切换 - 磁盘上的不同模式.

疯狂!

因此,请忘记关于原子性,一致性,隔离性,持久性的所有关于天使的针对性问题.房间里的大象就是如果你使用SQL Server并且你不是一家制药公司,它在大量人口中动态挖掘数据立方体以进行隐藏推理(是吗？)那么你可能正在使用错误的技术来存储你的数据.

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

RavenDB？我已经使用了一段时间(通过DB4O和CouchBase进化而来),我可以说它完成了它在锡上的说法.它存储我的东西,并在我问的时候把它还给我.我不必编写任何数据层也不必使用第三方ORM.我没有必要学习结构化查询语言,而且我没有必要使用附加功能来进行全文搜索工作(RavenDB基于Lucene,所以这一切都"正常").到现在为止还挺好.

但实际上,只要它是,对于手头的任务,易于编码,快速和有效,它是否重要？对于正常的应用程序开发,RavenDB就是所有这些东西,而SQL Server则不是.这并不是说关系数据库很糟糕 - 让我们不要责怪受害者 - 我完全承认,对于某些专门的开发,你可能确实需要一些更多......异国情调,这样的关系数据存储.

但是,万一你仍然坚持使用残骸,你需要问问自己:如果我们一直在使用简单,快速,优雅的数据存储,这些数据存储非常符合我们作为应用程序开发人员的需求,那么我写了一篇意见书,敦促你采用SQL Server然后你很可能会嘲笑我或者怜悯我.有一件事是肯定的 - 你不会交换到SQL Server.因此,我们证明了惯性本身就是使SQL Server成为主流的指导力量.惯性和无知.惯性,无知和企业贪婪......