MongoDB的必须具有的文档，其中包括其他文件的阵列的能力。这解决了许多您将在关系数据库中存在关系的情况。
当发票有多个职位时，您不会将这些职位放到单独的集合中。你可以将它们嵌入到数组中。
它让我想知道何时使用NoSQL与何时不使用现实生活中的例子？
有许多不同的NoSQL数据库，每个数据库的设计都考虑到不同的使用情况。但你把这个问题标记为MongoDB，所以我认为你的意思是特别是MongoDB。
与关系数据库相比，MongoDB有两个主要优势。
首先，它的尺度很好。
当数据库太慢或太大时，可以通过创建多个分片的集群或副本集来轻松添加更多的服务器。对于大多数关系数据库来说，这种方法几乎没有效果。
其次，它允许异构数据。
想象一下，例如，计算机硬件商店的产品数据库。产品有什么特性？所有产品都有价格和供应商。但CPU具有时钟频率，硬盘和RAM芯片有容量（这些容量不具有可比性），显示器具有分辨率等等。你如何在关系数据库中设计这个？你可以创建一个非常长的productID属性值表，或者你可以创建一个非常广泛和稀疏的产品表，其中每个属性都可以想象，但大多数产品的大多数都是NULL。这两种解决方案都不是很优雅。但是MongoDB可以更好地解决这个问题，因为它允许集合中的每个文档具有不同的属性集合。
它不能做什么？
作为一种相当新的技术，关于它的文献并不多。它周围的软件生态系统也不太好。您可以从关系数据库获得的工具通常更加有光泽。
也有一些使用情况MongoDB不太适合。
- 的MongoDB没有做连接。当你的数据非常关系并且非规范化时，它会适得其反，这对你的产品来说可能是一个糟糕的选择。但是你可能想看看像Neo4j这样的图形数据库，它比关系数据库更关注关系。 更新2016年： MongoDB 3.2现在与$lookup aggregation stage有着基本的JOIN支持，但与关系数据库和图形数据库相比，它的功能仍然非常有限。
- MongoDB不会处理事务。至少不复杂的交易。只影响单个文档的某些操作保证是原子性的，但只要影响多个文档，就不能保证其他查询不会在其间发生并找到不一致的状态。
- MongoDB不适合临时报告。它的数据挖掘选项受到严重限制。当你学会聪明地使用它时，相当新的聚合函数有助于MapReduce解决一些令人惊讶的复杂问题，但是SQL通常具有更好的工具。
通过非规范化的数据，你应该能够解决所有的相同的问题，关系型数据库做......但也有关于如何规范与关系数据库中的数据的规则。是否有规则可以帮助他们将数据非规范化以使用NoSQL解决方案？
关系数据库大约有40年。他们的理论在计算机科学中是一个经过深入研究的课题。有关于他们背后的理论的全部书籍都有书写。到目前为止，每个可以想象的角落案例都有一个解决方案。
另一方面，NoSQL数据库是一项相当新的技术。我们仍在搞清楚最佳做法。最常见的建议是：“用你自己的头脑，思考最常执行的查询，并为它们优化数据模式。”
关于什么时候可以考虑同时使用NoSQL解决方案和关系数据库的例子？
如果可能的话我会建议不要在同一产品中使用两种不同的数据库技术：
- 任何人谁维护和支持的产品必须熟悉这两种技术
- 故障排除得到了很多困难
- 系统管理员需要保持一个额外的数据库运行和更新
- 你有一个额外的故障点可能导致宕机
我只会建议在满足您的要求时混合使用数据库技术，但不会变得很难，但实际上不可能。否则，请选择并保持它。
NoSQL不仅仅是MongoDB。有许多新的数据库技术在标签下分组，它们具有完全不同的哲学和用例，它们的共同之处在于它们与SQL数据库也有共同之处。 – Philipp