面向文档的数据库的目标是减少“阻抗不匹配”,即在运行时将数据与驻留在内存中的实际对象中的某种数据库模式相匹配的程度。通过使用一个文档,整个对象被序列化到磁盘上,而无需在多个表中拆分并在检索时将它们重新连接在一起。
话虽如此,链接文档与引用文档相同。它们只是说同一件事的两种方式。这些链接在查询时的解析方式因一种数据库实现而异。
话虽如此,嵌入文档只是在父对象内部存储与父类型相关的对象类型的简单行为。比如我有一个类如下:
class User
{
string Name
List<Achievement> Achievements
}
其中Achievement 是一个任意类(其内容对于本示例无关紧要)。
如果我要使用链接文档保存它,我会将User 保存在用户集合中,将Achievement 保存在成就集合中,用户的成就列表链接到成就中的Achievement 对象收藏。这需要在数据库引擎本身中发生某种连接过程。但是,如果您使用嵌入式文档,您只需将 User 保存在用户集合中,其中成就位于 User 文档中。
嵌入文档的数据的 JSON 表示形式(大致)如下所示:
{
"name":"John Q Taxpayer",
"achievements":
[
{
"name":"High Score",
"point":10000
},
{
"name":"Low Score",
"point":-10000
}
]
}
而链接的文档可能如下所示:
{
"name":"John Q 纳税人",
“成就”:
[
“somelink1”,“somelink2”
]
}
在成就集合中
{
“somelink1”:
{
"name":"高分",
“点”:10000
}
“somelink2”:
{
"name":"高分",
“点”:10000
}
}
请记住,这些只是近似表示。
总而言之,链接文档的功能很像 RDBMS PK/FK 关系。这允许一个集合中的多个文档引用另一个集合中的单个文档,这有助于对存储的数据进行重复数据删除。然而,它增加了一层复杂性,要求数据库引擎进行多次磁盘 I/O 调用以形成最终文档以返回给用户代码。嵌入文档与内存中的对象更匹配,这减少了阻抗不匹配,并且(理论上)减少了磁盘 I/O 调用的数量。
您可以在此处阅读阻抗失配:http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
更新
我应该补充一点,从一开始就选择合适的数据库来满足您的需求是非常重要的。如果您对每个数据库有很多问题,联系每个供应商并获取他们的一些培训材料可能是有意义的。 MongoDB 提供 2 门免费课程,您可以通过 MongoDB University 了解有关其产品和最佳用途的更多信息。 OrientDB 确实提供培训,但它不是免费的。最好尝试直接与他们联系并接受某种售前培训(如果您希望获得数据库许可),通常他们会让您与某种售前顾问联系以帮助您评估他们的产品.