文档数据库与关系数据库：如何选择？

我是一个SQL专家，但我知道不仅有SQL数据库-大多数是文档数据库。与大多数技术一样，每种技术也各有利弊。

我读过一些文章，但是它们太理论化了。我想要的是两个真实的案例：

1. 从关系数据库到文档数据库的转换带来了改善
2. 从文档数据库到关系数据库的转换带来了改善

改进是指可以制定更好程序的任何事物-更少的开发时间，可扩展性，性能，以及与编程相关的任何事物。需要注意的是2 .：诸如“因为每个人都知道SQL而回退到关系数据库”之类的故事不好

最近几年选择NoSQL数据库的主要原因是可用性。对于像Amazon，Google和Facebook这样的公司来说，一个小时左右的停机时间是不可接受的。为了实现高可用性，您需要减少单点故障，这意味着您需要在多台计算机上使用分布式系统，以防计算机崩溃，该服务仍然可用。

传统的Relatione数据库在分布式多主机设置中不是很好。这就是为什么NoSQL最近如此流行。因此，如果您需要高可用性，则可以选择NoSQL数据库，例如Riak，Cassandra，HBase，S3或BigTable。

关于Amazon Dynamo的博客很好，很好地介绍了分布式NoSQL数据库。

现在，NoSQL的用语非常广泛，因此有许多未分发的NoSQL数据库。但是他们解决了其他问题。例如Neo4j-图形数据库非常适合传统RDBMS并未针对其优化的查询类型。或者像您的文档数据库一样，如果要为某些文档添加某些字段，则无需更改架构。换句话说，当大多数帖子（文档）具有不同的字段时，文档数据库是好的，因此无法使用具有预定义列的关系表。

但是，大多数NoSQL数据库都不像传统的RDBMS数据库那样灵活，因此在无法解决问题之前，使用传统的RDBMS数据库是一个不错的选择。

我有一种简单的方法来确定最适合数据的数据库。

我只是问自己：假设我没有数据库，我宁愿将最重要的数据保存为文档，还是将其存储在电子表格中。

当答案是“电子表格”时，这清楚地表明关系模型和传统RDBMS在大多数情况下最适合任务。如果数据真的很简单，例如仅键值对或简单表，并且引用完整性不是主题，那么NoSQL数据库可能最适合该任务，并且可以大大提高性能！

另外，当您根本找不到通用结构时，NoSQL数据库最适合该任务。

当数据更像文档时，例如没有明确关系的分层结构的文本数据，那么我立即想到了XML数据库，它可以轻松地存储分层结构的文档。但是，有时最好使用文档管理软件。

因此，为了对您的两个问题给出具体而简单的答案：这取决于数据。

从关系数据库到文档数据库的转换带来了改善

当您需要保留层次结构的文本数据时，Xml数据库在可维护性和可伸缩性方面都可以是一个很大的改进。

从文档数据库到关系数据库的转换带来了改善

好吧，例如，当数据大多是具有清晰关系的表格形式时，您需要保证完整性。

我们不得不放弃关系模型，因为我们获得的数据没有简单，明显，固定的静态模式。

用户-和用户故事-没有固定的静态模式。

我们试图强加一个固定的，静态的RDBMS模式，但这是一个错误。

每个第三方（从客户和供应商处）的数据传递都相似，但不完全相同。我们尝试将其映射到固定的关系模式，但是可变性太大。我们要么必须在每个文件中添加字段（每周几个），要么必须脱离固定的静态关系模式。

如果我们将每条记录视为具有共同的元素子集和唯一的（以及定义不明确的）附加数据元素集合的“文档” ，那么我们会非常高兴。

用户定义用例时实际需要的数据元素定义不正确。

关系模型的固定，静态模式不适合我们的用例。