моделирования Neo4j DB - отношения и родительские узлы

Question

Доброго утра,

Я начинаю двигаться из реляционной БД Нео и, таким образом, перенося своим «стол-мышление» в графе мир. Думая о модели, чтобы представить мой модуль задачи мне нужно поставить следующие объекты в отношении:

• клиента
• Задача
• Пользователь

Так что я пришел с этой идеей:

(CUSTOMER)-[:GENERATES]->(TASK) 
(USER)-[:IS_ASSIGNED_TO]->(TASK) 

Я размышлял, когда я собираюсь запросить это, я бы назвал каждый узел задачи меткой TASK и havi ng статус как свойство, например. закрытая, открытая и т.д.

Глядя теперь все открытые задачи могли были решены

MATCH (t:TASK {status:"open"}) -[:IS_ASSIGNED_TO]-> (u:USER) 
MATCH (c:Customer) -[:GENERATES]-> (t:TASK) 
RETURN t.number as task_number, c.name as customer_name, u.name as user_name 

При создании узлов и отношений мне было интересно, если я просто создать узел для задачи, один для пользователя и один для клиента и подключить их, как к модели выше, или если мне нужно будет иметь что-то вроде «родительского узла» каждого типа узлов, например GENERAL_USER, GENERAL_TASK и GENERAL_CUSTOMER и связав каждый отдельный узел с этим родителем, а также с отношением, которое охватывает текущий статус. Идея заключалась в том, что когда я хочу иметь открытые задачи, мне может быть проще начать с узла GENERAL_TASK и найти все отношения к задачам, у которых есть статус OPEN, а не искать каждый узел, который может быть где-то в БД. Это быстрее, чем попросить БД вернуть все узлы TASK, у которых есть статус свойства с содержимым OPEN (даже если оно индексировано)?

Был бы рад иметь какой-то вклад, чтобы лучше понять, как моделировать БД и отношения. Спасибо за ваше время.

Answer 1

Итак, я думаю, вы думаете в правильном направлении здесь. Выбирая, как лучше всего моделировать данные, шаблон запроса имеет большое значение.

В общем, neo4j настроен так, чтобы сделать обходные отношения дешевыми. Так как общее правило, будет дешевле ориентироваться в отношениях, чем будет сканировать все ваши узлы для тех, у которых есть определенное значение свойства.

Если определенная группировка состояний заданий будет часто запрашиваться, тогда, вероятно, имеет смысл связать задачи с этим «классом» задач в вашей модели. Просто убедитесь, что вы правильно поддерживаете эти ссылки. Одним из недостатков является то, что узел может быть связан с двумя разными статусами (что может не иметь смысла в вашей модели), тогда как если узел имеет статус «свойство», тогда он может иметь только одно значение при время. По мере того, как ваши задачи будут обработаны, их статус изменится, и ваш код должен будет убедиться, например, что все задачи связаны с одним и только одним статусом.

Предположим, что у вас есть дискретная переменная (т. Е. Переменная, которая может принимать только один фиксированный набор значений, например, код состояния или флаг состояния). Когда вы должны сделать это отдельным узлом и когда вы должны сделать это свойство узла?Там нет жестких и быстрых ответов, но вот несколько рекомендаций:

Вещи, которые позволили бы предположить, он должен быть узлом

1. Частой необходимости фильтрации больших наборов результатов этого конкретного значением
2. это отношение к более чем одного типа узла (т.е. задачи имеют статус, но пользователи могут быть связаны с определенным статусом тоже)

вещи, предполагающие бы это должно быть ар roperty

1. Это относится только к одному типу узла
2. Число значений очень мал (т.е. < 5)
3. Infrequent выполнения запроса на основе этого свойства