#neo4j
#neo4j
Вопрос:
Я только изучаю Neo4j и хочу создать систему, которая позволяет мне иметь темы, в каждой из которых могут быть родители или дети, но не всегда очевидно, является ли это родителем или дочерним элементом, и отношения не всегда одного типа.
Если вы посмотрите на пример Neo4j здесь, он использует этот код:
(:Person {name: string})-[:ACTED_IN {roles: [string]}]->(:Movie {title: string, released: number})
Это работает, когда вы знаете, что это фильмы. В этом случае узел имеет Movie тип. Если вы создаете что-то, в чем сегодня есть фильмы, а завтра будет совершенно другая тема, например, руководители, тогда movie это уже не актуально, как и отношения ACTED_IN . Как люди обычно справляются с этими сценариями, когда они хотят, чтобы их код был управляемым по мере изменения их «тем» или типов узлов, особенно когда типы узлов могут быть просто более общими thing с самого начала.
Может быть, что-то вроде:
Tom Hanks IS_CHILD_OF Forrest Gump вместо Tom Hanks ACTED_IN Forrest Gump
но как вы определяете направленность этого теперь, когда имя отношения настолько общее? Является ли актер дочерним элементом своего фильма или фильм теперь дочерним элементом актера?
Главный вопрос, который у меня есть, заключается в том, как я могу защитить от будущего, чтобы у меня был общий thing вместо movie или ceo или hot_sauce узлов. Итак, если завтра тема будет о генеральных директорах, у вас есть Tim Cook IS_CHILD_OF Apple или что-то в этом роде?
Кроме того, это просто крайне неэффективно? Если да, то, если имена типов узлов и отношений чрезвычайно динамичны, как вы отслеживаете их и знаете, что запрашивать и когда?
Комментарии:
1. Как правило, типы отношений всегда должны быть как можно более конкретными, что помогает Neo4j обрабатывать как можно меньше данных по мере необходимости. В идеале обходы нужно просто фильтровать по меткам узлов и типам отношений. Продолжая ваш пример, действительно ли ваш набор данных эволюционирует от фильмов к руководителям? Если нет, я бы лично сначала убедился, что запросы в настоящее время хорошо выполняют свою работу, прежде чем беспокоиться о возможных неизвестных будущих деталях.
2. Я думаю, что они могли бы. Просто представьте себе сценарий, в котором я хочу поддерживать узлы для всех типов «вещей», сегодня это могут быть фильмы, а завтра — виды острых соусов. При этом стало бы неуправляемым поддерживать, казалось бы, бесконечное количество типов отношений. Я думаю?
3. Если ваши данные могут стать чем угодно, тогда да, я согласен, это может быть сложно смоделировать. Но насколько реалистичен этот сценарий? И если ваш набор данных полностью изменится, проблема будет не только в базе данных (приложения должны будут измениться, предварительные продажи должны будут изменить их высоту …)
4. Это хороший вопрос, но думаю, что идея немного не в себе. Разрабатывается то, с чем вы можете взаимодействовать с чем угодно, так что это похоже на страницы Facebook, где вы можете следить за ними, но однозначно вы можете сказать, что другая страница связана с / дочерним элементом другой. Если бы Facebook реализовал страницы, где страницы могли быть любыми, но тогда вы могли бы соединить любые две страницы, как вы думаете, вы могли бы их соединить? Например, если Tesla хочет связать свою страницу FB с SpaceX, или с Moon, или с Илоном Маском, в этом случае у вас есть две компании, 1 место и 1 знаменитость, но все они «Вещи»?
Ответ №1:
На мой взгляд, защита от будущего — опасный путь 🙂 Тем не менее, если система, которую вы создаете, является общей, тогда должны быть некоторые основные концепции, на которые вы моделируете. Темы, которые имеют отношения родитель-потомок, или страницы, которые связаны друг с другом. Они достаточно хороши для моделирования, поскольку вы можете протестировать модель на основе вопросов, которые вы ей задаете.
При графическом моделировании вопросы / варианты использования предшествуют модели, поэтому я бы начал с этого — на что вы хотите, чтобы график ответил? Примеры: Какие страницы связаны с Tesla? Или, как связаны темы A и B? Без этих вопросов ваша графическая модель может варьироваться от несколько адекватной до неэффективной и подходящей для конкретного случая. Как только у вас возникнут вопросы, тогда сущности / узлы должны начать немедленно выскакивать на вас, а также отношения.
Самый близкий пример из реального мира, который я могу придумать, — это модель ПОЛЮСА, которая основывается на четырех типах понятий — Человек, объект, местоположение, событие. Все в этом домене встроено в один из этих четырех. Это придает модели несколько «общий» вид, в то же время позволяя выполнять разумные запросы, такие как, какие события произошли в этом месте с участием этого человека и этого объекта.
Вы могли бы дополнительно абстрагировать это от одного типа узла, называемого Entity, и одного типа отношений, называемого RELATED или similar, но тогда вам нужно встроить целый слой метаданных, чтобы понять, что на самом деле указывает эта структура. Ваша база данных станет не более чем хранилищем связанных фрагментов информации, и вы делегируете бизнес-логику приложению, формируя запросы на основе метаданных. Может быть, это то, что тебе нужно.
С точки зрения производительности было бы очень сложно сказать, потому что весь график выглядит одинаково — возможно, у вас будут очень плотные узлы, возможно, вам придется просматривать все отношения из этих плотных узлов и отфильтровывать их по свойствам. Индексы не принесли бы большой пользы, если бы у вас была только одна метка. Итак, по сути, эта модель определенно возможна, но если вы идете по этому пути, тогда стоило бы изучить, что база данных graph привносит в ваш домен / приложение, чтобы убедиться, что эти компромиссы того стоят.