在为 Web 应用程序选择数据层时应考虑哪些方面？
使用文档数据库而不是关系数据库，在开发大型和重载的小型项目时，是否有任何更好的选择，反之亦然？
这些方法首选哪种数据库架构 - 如果我有没有太多关系的简单数据库，使用一种方法比另一种方法更好吗？
问问题
6767 次
1 回答
56
由于这个问题是邀请个人评论，这是我的意见：
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 成为主流的指导力量。惰性和无知。惰性、无知和企业贪婪....
于 2012-05-09T15:13:53.903 回答