问题标签 [document-oriented-db]

据我了解，您可以将任何非结构化信息输入到面向文档的数据库中。让我们想象一个这样的文档：

后来，在新版本中，这个结构被重构为

您如何使用面向文档的数据库来做到这一点？您是否必须准备合并脚本来更改数据库中的所有条目？还是有更好的方法可以处理结构的变化？

最近我一直在使用MongoDB，我不得不说我真的很喜欢它。然而，它是一种完全不同类型的数据库，然后我使用它。我注意到它对于某些类型的数据肯定更好，但是对于高度规范化的数据库，它可能不是最佳选择。

然而，在我看来，它可以完全取代您可能拥有的任何关系数据库，并且在大多数情况下性能更好，这令人难以置信。这让我问了几个问题：

1. 面向文档的数据库是否正在发展成为下一代数据库并基本上完全取代关系数据库？
2. 对于更适合其中一个或另一个的各种数据，项目是否可能会更好地同时使用面向文档的数据库和关系数据库？
3. 如果面向文档的数据库不打算取代关系数据库，那么有没有人有一个数据库结构的例子，在关系数据库中绝对会更好（反之亦然）？

只是想知道在设计面向文档的数据库时是否有任何指导方针，我特别谈论的是CouchDb。

我知道无模式事物可以形成我们想要的形状，但是，有什么最佳实践吗？

提前致谢！=D

我正在尝试使用 mongo db 实现博客文章存储。

我有两个域实体：

“博文”和“作者”

目前我已将 AuthorId 属性添加到博客文章实体。这是存储对象之间关系的正确方法吗？

问候，

我正在使用 php 构建我的个人网站。我的标准方法是使用 MySQL 作为数据库后端。我听说过很多关于面向文档的数据库，我想知道这些（couchDB、mongoDB）对我来说是否是一个更好的选择。

我知道像我的个人主页这样的低流量网站不会因为运行不同的数据库而获得巨大的改进，但我很欣赏“小事”。

该数据库将主要保存文本数据，例如评论和博客文章。除此之外，我将存储一些图像。

总而言之，谁能给我一个优点和缺点，或者对使用特定数据库后端的其他批评，尤其是新的面向文档的后端？

谢谢。

我正在寻找创建一个简历银行，当我考虑将数据存储在关系数据库中时，复杂性非常明显。在这种情况下，couchdb 会更有意义吗？

我要存储的东西的例子

每个与用户教育、资格、就业、奖励、语言、技能、许可证、协会的一对多关系

我正在研究一些面向文档的商店的成熟度，其中包括在生产环境中使用数据库的应用程序和网站的概述。有几个可用于 CouchDB 和 MongoDB 的列表和案例研究，包括：

• CouchDB 在野外
• MongoDB 生产部署

我很难找到在生产中使用 RavenDB 的应用程序和网站。有没有人有这方面的第一手经验，或者在 RavenDB 上运行的（知名）网站的例子？

我已经听到很多关于无模式（通常是分布式）数据库系统的讨论，比如 MongoDB、CouchDB、SimpleDB 等......

虽然我可以理解它们对于某些目的可能很有价值，但在我的大多数应用程序中，我都试图保留具有特定类型的特定数量字段的对象，并且我只是自动在关系模型中思考。我一直在考虑具有唯一整数 id 的行、null/not null 字段、SQL 数据类型以及用于查找集合的选择查询。

虽然我被这些新系统的分布式特性和简单的 JSON/RESTful 接口所吸引，但我不明白松散类型的键/值哈希对我的开发有何帮助。为什么松散类型、无模式的系统有利于保持干净的数据集？例如，当它们可能没有日期时，我怎样才能找到日期在 x 和 y 之间的所有项目？有加入的概念吗？

我知道许多系统都有自己的差异和优势，但我想知道范式的差异。我想这是一个开放式的问题，但也许社区的答案和他们个人看到这些系统优势的方式将有助于启发我和其他人什么时候想要使用这些（诚然更时髦的）系统而不是传统的关系型数据库。

可能的重复：
无模式数据库系统的吸引力是什么？

与关系数据库相比，面向文档的数据库有哪些优势？我应该在哪里使用面向文档的数据库？

我想先说我猜没有真正的实际问题，但我觉得很奇怪没有一些系统来管理这些事情。

我们目前有大量位于目录层次结构中的 XML 文件。我认为在这些文件夹周围使用一些面向文档的数据库可能很有用。它可能对搜索非常有用，但目前我们不需要搜索。

我正在努力考虑目前甚至拥有数据库的实际业务原因。它可以为我们提供“加速我们的系统”的机会，但我怀疑可扩展性永远不会成为问题。

还有什么我没有考虑过的吗？