могут эти типы данных, используемые в графе d b of orientdb?В orientDB могут использоваться следующие типы данных в графической базе данных orientDb или возможно только в базе данных документов orientDb?
Их можно использовать в обоих случаях. Как указано в OrientDB docs (некоторые приведенные ниже параграфы), API-интерфейс Graph DB построен поверх API-интерфейса Document DB.
Когда вы создаете ребро в графе DB, API-интерфейс Graph создаст краевой документ с вставками и ссылками, указывающими на документы вершин, а также входы и выходы на вершинных документах, указывающих на край (это не легкие края).
Для сравнения, при создании ссылки между документами это только «указатель одного пути» из одного документа в другой, поэтому второй не знает, что он был связан. Вы также можете вручную создавать ссылки таким образом с документами вершин/границ, в ситуациях, когда вам не нужны указатели стиля полного графа.
В OrientDB мы создали два разных API: API документа и графический API. API-интерфейс Graph работает над API-интерфейсом документа. API документов содержит модели Document, Key/Value и Object Oriented.
График API
{надрез}
- Отношения смоделированы как Двунаправленный Ребра. Если активна настройка «Весовая граница», OrientDB использует Lightweight Edges в случаях, когда ребра не имеют свойств, поэтому они оказывают такое же влияние на скорость и пространство, что и на Document LINK, но с дополнительным бонусом для двунаправленных соединений. Это означает, что вы можете использовать команду MOVE VERTEX для рефакторинга графика без прерывания LINK. Для получения дополнительной информации о том, как Edges управляются, смотрите Lightweight Edges.
документа по API
{надрез}
- Отношения только Моно Направленная. Если вам нужны двунаправленные отношения, вы несете ответственность за поддержку обоих LINK.
- Документ представляет собой атомную единицу, а с графиками все связано как с &. По этой причине операции Graph должны выполняться внутри транзакций. Вместо этого, когда вы создаете связь между документами с LINK, целевой документ не участвует в этой операции. Это приводит к лучшей поддержке Multi-Thread, особенно при вставке, удалении и обновлении операций.
Встроенные документы имеют различный вариант использования, хотя, и работать с регулярными документов и графиков на основе документов. Как указано в разных местах 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.
Для практического примера, скажем, у вас есть документы Person и E-mail, тогда вы вставляете электронное письмо в человека - письмо тогда не будет присутствовать, если вы select from Email. Если вы создадите ссылку от лица к электронной почте, будет создана отдельная запись электронной почты, но вы бы не знали *, который использовал каждое электронное письмо при запросе электронной почты. Однако, если вы использовали ребро (например, используйте график db api, который будет создавать и поддерживать ссылки для вас), вы сможете найти, кто из пользователей использовал электронную почту при запросе электронной почты.
* Вы всегда можете запросить у каждого человека, чтобы найти, какие записи ссылаются на конкретный адрес электронной почты, но при этом не учитывается использование базы данных графа.