在orientDB中，以下數據類型可以在orientDb的圖形數據庫中使用還是只能在orientDb的文檔數據庫中使用？

Question

1. 嵌入式的
2. 嵌入式清單
3. 嵌入式套裝
4. 嵌入式地圖
5. 鏈接
6. 連結清單
7. 鏈接集
8. 鏈接圖

可以在orientdb的圖形數據庫中使用這些數據類型嗎？

Answer 1

它們可以在兩者中使用。 正如OrientDB文檔 （在下面引用的一些段落）中指出的那樣，Graph DB API建立在Document DB API之上。

當您在Graph DB中創建邊緣時，Graph API將創建一個邊緣文檔，其中包含指向頂點文檔的in和out鏈接，以及指向邊緣的頂點文檔上的in和out鏈接（這沒有輕量級的邊緣）。

相比之下，當您在文檔之間創建鏈接時，它只是從一個文檔到另一個文檔的“單向指針”，因此第二個文檔不知道它已被鏈接。 在不需要完整圖形樣式指針的情況下，也可以通過這種方式手動創建與頂點/邊文檔的鏈接。

在OrientDB中，我們創建了2個不同的API：文檔API和圖形API。 Graph API在Document API之上運行。 文檔API包含文檔，鍵/值和面向對象的模型。

圖形API

{snip}

• 關系被建模為雙向邊。 如果“輕量級邊緣”設置處於活動狀態，則OrientDB在沒有屬性的情況下會使用“輕量級邊緣”，因此它對速度和空間的影響與文檔鏈接相同，但具有雙向連接的額外好處。 這意味着您可以使用MOVE VERTEX命令來重構圖形，而不會損壞LINK。 有關如何管理邊緣的更多信息，請參見輕量級邊緣。

文件API

{snip}

• 關系僅是單向的。 如果您需要雙向關系，則有責任維護兩個LINK。
• 文檔是原子單位，而對於Graphs，所有內容都按輸入和輸出連接。 因此，必須在事務中完成圖操作。 相反，當您使用LINK創建文檔之間的關系時，此操作不涉及目標鏈接的文檔。 這樣可以更好地支持多線程，尤其是在插入，刪除和更新操作方面。

但是，嵌入式文檔具有不同的用例，可與常規文檔和基於圖形的文檔一起使用。 如文檔中各個位置所示， The Records are contained inside the owner. The contained records have no RecordIds and are reachable only by navigating the owner record 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時，該電子郵件將不存在。 如果您創建了從“人”到“電子郵件”的鏈接，將有一個獨立的電子郵件記錄，但是您不會知道 *查詢電子郵件時是誰使用了每個電子郵件。 但是，如果您使用邊緣（例如，使用graph db api，它將為您創建和維護鏈接），那么您將能夠在查詢電子郵件時找到使用電子郵件的人。

* 您總是可以查詢每個人，以查找哪些記錄鏈接到特定的電子郵件，但是這樣做首先錯過了使用圖形數據庫的意義。