Объектно-ориентированное программирование в базах данных Graph

Базы данных графов хранят данные в виде узлов, свойств и отношений. Если мне нужно получить некоторые конкретные данные из объекта на основе запроса, мне нужно будет получить несколько объектов (поскольку запрос может иметь много результатов).

Рассмотрим этот простой сценарий объектно-ориентированного программирования в графовых базах данных:

У меня есть (граф) база данных пользователей, где каждый пользователь хранится как объект. Мне нужно получить список пользователей, живущих в определенном месте (свойство места хранится в объекте пользователя). Итак, как бы я это сделал? Я имею в виду, что ненужные данные будут извлекаться каждый раз, когда мне нужно что-то сделать (в этом случае может потребоваться извлечение всего пользовательского объекта). Разве функциональное программирование не лучше в графовых базах данных?

Этот пример является просто простой аналогией поставленного выше вопроса, который пришел мне в голову. Не принимайте это за эталон. Итак, остается вопрос: Насколько хорошо объектно-ориентированное программирование в графовых базах данных?


database oop neo4j functional-programming graph-databases
person c0da    schedule 06.08.2011    source источник
comment
Я бы предпочел создать узлы мест и подключить к ним пользователей с помощью отношений. - Зачем использовать графическую базу данных так же, как и какое-то хранилище, не связанное с графикой?! Насколько я знаю, все графовые базы данных поддерживают индексирование, поэтому вы можете использовать его вместо проверки значений свойств по одному. - Я думаю, вы смешиваете две разные проблемы: использование объектно-ориентированного программирования не означает, что вы должны постоянно загружать полные объекты из БД. Может быть, вы могли бы попытаться сделать вопрос более ясным?   -  person nawroth    schedule 08.08.2011

Ответы (4)


arrow_upward
1
arrow_downward

Каждый узел имеет атрибуты, которые можно сопоставить с полями объекта. Вы можете сделать это вручную или использовать spring-data для сопоставления.

person Bozho    schedule 06.08.2011

arrow_upward
3
arrow_downward

База данных графа — это больше, чем просто вершины и ребра. В большинстве графовых баз данных, таких как neo4j, в дополнение к вершинам, имеющим id, и ребрам, имеющим label, у них есть список свойств. Обычно в графовых базах данных на основе Java эти свойства ограничены примитивами Java — все остальное необходимо сериализовать в строку (например, даты). Это сопоставление со свойствами вершин/ребер можно выполнить либо вручную, используя такие методы, как getProperty и setProperty, либо что-то вроде Frame, сопоставитель объектов, использующий стек TinkerPop.

person Pridkett    schedule 06.08.2011

arrow_upward
1
arrow_downward

Большинство баз данных графов имеют по крайней мере один тип индекса для вершин/ребер. InfiniteGraph, например, поддерживает B-Trees, Lucene (для текста) и тип распределенного масштабируемого индекса. Если у вас нет индекса для поля, которое вы пытаетесь использовать в качестве фильтра, вам нужно будет пройти по графу и самостоятельно применять предикаты на каждом этапе. Надеюсь, это уменьшит количество узлов, которые необходимо пройти.

person TobyTheDog    schedule 08.08.2011

arrow_upward
0
arrow_downward

Blockquote Мне нужно получить список пользователей, живущих в определенном месте (свойство места хранится в объекте пользователя).

Существует лучший способ. Отдельное местоположение от пользователя. Вместо местоположения в качестве свойства создайте узел для местоположений. Таким образом, у вас может быть (u:User)-[:LIVES_IN]->(l:Location) тип отношений.

становится проще получить список пользователей, живущих в определенном месте, с помощью простого запроса:

match(u:User)-[:LIVES_IN]->(l:Location) where l.name = 'New York'.
return u,l.

Это вернет всех пользователей, живущих в Нью-Йорке, без необходимости сканирования всех свойств каждого узла. Это более быстрый подход.

person user3604212    schedule 27.10.2015