在为 Web 应用程序选择数据层时应考虑哪些要点？
使用文档数据库而不是关系数据库，同时开发大型和重负载的小型项目，反之亦然，是否有任何更好的选择？
这些方法首选哪种数据库体系结构 - 如果我有没有太多关系的简单数据库，那么使用一种方法比使用另一种方法更好吗？
由于这个问题是邀请个人评论，这是我的意见：
SQL Server 不是用于存储除即席报告数据之外的任何内容的数据库。它非常适合临时报告，数据挖掘，实时关系发现 - 以及它最适合这些用途，因为早在Codd设计规则时，这就是它的设计目的(有关更多详细信息，请参阅数据驱动的阴谋(
当然，您可以在关系数据库中存储其他类型的数据。例如，您可以将域状态序列化为 SQL Server 数据库，并在以后检索该状态，但这是对关系系统的糟糕使用。事实上，如此糟糕，以至于需要数千行代码的整个代码层(所谓的"数据层"或DAL(才能使这种任务远程可操作，可测试，可维护。
长达数十年的伟大信心技巧是，基于SQL的零售商说服我们，除了在完全不同的数据结构之间进行实时转换之外，没有更好的方法来存储分层/文档数据。DAL和最新的ORM都被吹嘘了，但最终，这些只不过是编解码器，可以在不同的数据组织之间来回切换 - 磁盘上的不同模式。
疯狂！
所以忘记所有关于原子性、一致性、隔离性、持久性的尖锐、天使式的争论吧。房间里的大象是，如果你使用的是SQL Server，而你不是一家在大量人群中动态挖掘数据立方体以隐藏推理的制药公司(你是吗？(，那么你可能使用了错误的技术来存储你的数据。
另一方面，如果你是一个谦虚的应用程序开发人员 - 一个编码员，像我们大多数人一样，只是希望以一种并不意味着学习一套全新的意识形态和语法的方式序列化域状态，那么，为了善良，不要使用关系数据库。只是不要。
乌鸦数据库？我已经使用它一段时间了(通过DB4O和CouchBase发展而来(，我可以说它做到了它在锡上所说的。它存储我的东西，并在我询问时还给我。我不必编写任何数据层，也不必使用第三方ORM。我不必学习结构化查询语言，也不必附加功能即可使全文搜索工作(RavenDB基于Lucene，因此一切都"正常工作"(。目前为止，一切都好。
但实际上，对于手头的任务，易于编码，快速高效，您使用什么重要吗？对于正常的应用程序开发，RavenDB是所有这些东西，而SQL Server不是。这并不是说关系数据库不好 - 我们不要责怪受害者 - 我完全承认，对于某些专业开发，您可能确实需要更多的东西......异国情调，这样的关系数据存储。
但以防万一你仍然坚持残骸，你需要问问自己：如果我们都一直在使用简单、快速、优雅的数据存储，这些数据存储非常符合我们作为应用程序开发人员的需求，然后我写了一篇评论文章，敦促你采用 SQL Server，那么你很可能会嘲笑我或同情我。有一件事是肯定的 - 你不会交换到SQL Server。因此，我们证明了惯性本身是使SQL Server成为主流的指导力量。惰性和无知。惰性，无知和企业贪婪....