可以在orientdb的图表db中使用这些数据类型吗？
答案 0 :(得分：1)
它们可用于两者。正如OrientDB docs（下面引用的一些段落）所指出的，Graph DB API建立在Document DB API之上。
在Graph DB中创建边时，Graph API将创建一个边缘文档，其中包含指向顶点文档的输入和输出链接，以及指向边缘的顶点文档上的输入和输出链接（这不是轻量级的）边缘）。
相比之下，当您在Documents之间创建链接时，它只是从一个文档到另一个文档的“单向指针”，因此第二个不知道它已被链接。在不需要完整图形样式指针的情况下，您也可以使用顶点/边缘文档以这种方式手动创建链接。
在OrientDB中，我们创建了两个不同的API：Document API和Graph API。 Graph API在Document API之上工作。 Document API包含Document，Key / Value和面向对象的模型。
图表API
{剪断}
- 关系被建模为双向边缘。如果轻量级边缘设置处于活动状态，则OrientDB在边缘没有属性的情况下使用轻量边缘，因此它对文档链接具有与速度和空间相同的影响，但具有双向连接的额外奖励。这意味着您可以使用MOVE VERTEX命令重构图形而不会丢失LINK。有关如何管理边缘的更多信息，请参阅轻量边缘。
文档API
{剪断}
- 关系只是Mono Directional。如果您需要双向关系，则您有责任维护两个链接。
- 文档是一个原子单元，而使用Graphs，所有内容都连接为In＆amp;出。因此，Graph操作必须在Transactions中完成。相反，当您使用LINK在文档之间创建关系时，目标链接文档不会参与此操作。这样可以提供更好的多线程支持，尤其是插入，删除和更新操作。
嵌入式文档具有不同的用例，并且可以使用常规文档和基于图形的文档。如in the docs，The Records are contained inside the owner. The contained records have no RecordIds and are reachable only by navigating the owner record所示。
对于一个实际示例，假设您有人员和电子邮件文档，然后您将电子邮件嵌入到某个人中 - 当您select from Email时，该电子邮件将不会出现。如果您创建从人员到电子邮件的链接，则会有一个独立的电子邮件记录，但您不会知道 *在查询电子邮件时使用了每封电子邮件。如果您使用了边缘（即使用图形db api，它将为您创建和维护链接），那么您将能够在查询电子邮件时找到哪个人使用了电子邮件。
* 您可以随时查询每个人以查找哪些记录链接到特定的电子邮件，但这样做首先忽略了使用图表数据库的重点。