MongoDB 能够拥有包含其他文档数组的文档。这解决了许多在理性数据库中存在关系的情况。
当发票有多个位置时，您不会将这些位置放入单独的集合中。您可以将它们嵌入为数组。
这让我想知道什么时候使用 NoSQL 和什么时候不使用的真实例子？
有许多不同的 NoSQL 数据库，每一个都在设计时考虑了不同的用例。但是您将此问题标记为 MongoDB，所以我假设您特别指的是 MongoDB。
与关系数据库相比，MongoDB 有两个主要优势。
首先，它可以很好地扩展。
当数据库太慢或太大时，您可以通过创建集群或多个分片的副本集轻松添加更多服务器。这在大多数关系数据库中几乎不起作用。
其次，它允许异构数据。
例如，想象一下计算机硬件商店的产品数据库。产品有哪些特性？所有产品都有价格和供应商。但是 CPU 有时钟频率，硬盘驱动器和 RAM 芯片有容量（这些容量没有可比性），显示器有分辨率等等。您将如何在关系数据库中设计它？您可以创建一个非常长的 productID-property-value 表，或者创建一个非常宽且稀疏的产品表，其中包含您可以想象的每个属性，但其中大多数是NULL针对大多数产品的。这两种解决方案都不是很优雅。但是 MongoDB 可以更好地解决这个问题，因为它允许集合中的每个文档具有一组不同的属性。
它不能做什么？
作为一项相当新的技术，关于它的文献并不多。它周围的软件生态系统也不是很好。您可以获得的用于关系数据库的工具通常更加闪亮。
还有一些用例 MongoDB 并不适合。
- MongoDB 不做 JOIN。当您的数据非常相关并且非规范化会适得其反时，它可能是您产品的糟糕选择。但是你可能想看看像 Neo4j 这样的图形数据库，它比关系数据库更关注关系。2016 年更新： MongoDB 3.2 现在具有$lookup 聚合阶段的基本 JOIN 支持，但与关系和图形数据库相比，它的功能仍然非常有限。
- MongoDB 不做事务。至少不是复杂的交易。某些只影响单个文档的操作保证是原子的，但是一旦您影响多个文档，您不能保证中间不会发生其他查询并找到不一致的状态。
- MongoDB 不适合临时报告。它的数据挖掘选项受到严重限制。相当新的聚合函数有帮助，当你学会聪明地使用它时，MapReduce 也可以解决一些令人惊讶的复杂问题，但 SQL 通常有更好的工具来处理类似的事情。
通过对数据进行非规范化，您应该能够解决关系数据库所做的所有相同问题......但是关于如何使用关系数据库对数据进行规范化是有规则的。是否有可以用来帮助他们对数据进行非规范化以使用 NoSQL 解决方案的规则？
关系数据库已经存在了大约 40 年。他们的理论是计算机科学中一个经过充分研究的课题。有很多关于它们背后的理论的书籍。到目前为止，对于每个可以想象的极端情况，都有一个按规定的解决方案。
但另一方面，NoSQL 数据库是一项相当新的技术。我们仍在寻找最佳实践。最常见的建议是：“用你自己的头脑。想想最常执行的查询，并为它们优化你的数据模式。”
关于何时您可能需要考虑同时使用 NoSQL 解决方案和关系数据库的任何示例？
如果可能，我建议不要在同一产品中使用两种不同的数据库技术：
- 任何维护和支持产品的人都必须熟悉这两种技术
- 故障排除变得更加困难
- 系统管理员需要保持额外的数据库运行和更新
- 您有一个额外的故障点，可能导致停机
我只建议在满足您的要求时混合使用数据库技术，而没有它不仅变得困难而且在物理上是不可能的。否则，请选择并坚持下去。