(neo4j) Лучшая практика для количества свойств в отношениях и узлах - PullRequest
0 голосов
/ 14 ноября 2018

Я только начал использовать neo4j и, проведя несколько экспериментов, готов начать организовывать базу данных сама по себе. Поэтому я начал с разработки базовой схемы (на бумаге) и натолкнулся на следующее сомнение:

Большинство примеров в материале, который я использую (уроки по cypher и neo4j), содержат только несколько свойств на отношение / узел. Но я должен задаться вопросом, какова стоимость наличия тяжелой цепочки свойств.

Q: Является ли более эффективным предпочтение широкого спектра типов отношений (GOODFRIENDS_WITH, FRIENDS_WITH, ACQUAINTANCE, RIVAL, ENEMIES и т. Д.) Или меньшего количества типов с различными свойствами (тип SEES_AS: хороший друг, друг , знакомый, соперник, враг и т. д.)?

То же самое верно для узлов. Первый черновик моей диаграммы имеет ошеломляющее количество свойств (название, имя, фамилия, имя, фамилия, вторая фамилия, суффикс, псевдоним, а также есть физические характеристики, личность, возраст, работа ...) и я думая, что это может снизить производительность БД. Конечно, некоторые узлы не будут нуждаться во всех свойствах, но базовых свойств все еще будет немало.

Q: Каков фактический и рекомендуемый предел для количества свойств как в узлах, так и в отношениях?

К вашему сведению, я собираюсь переделать черновик таким образом, чтобы уменьшить свойства, используя вместо этого узлы (создайте узел: имена семей, другой для: job и т. Д.), Но я только начал думать все закончится, так как мне нужно будет тщательно проанализировать, какие «потенциальные свойства» имеют смысл оставить, даже если изменение увеличит количество типов отношений, с которыми я буду иметь дело.

Справочная информация:

1) Я использую neo4j, чтобы наметить все отношения между людьми, живущими в вымышленном маленьком городке. В основном я буду выполнять следующие запросы:

а. найти все возможные пути между 2 (или более) символами

б. найти все места, в которых часто встречаются 2 (или более) символа

с. найти всех персонажей, которые имеют определенные типы отношений (друзья, двоюродные братья, соседи и т. д.) с персонажем X

* * +1034 д. найти всех персонажей того же возраста (или того же возраста), которые учились в одной школе

е. найти всех персонажей с одинаковым возрастом / именем / фамилией / цветом волос / ростом / хобби / работой / характером (легко разозлить) / ...

и варианты выше.

2) Я не программист, но, имея самообученный HTML и продвинутый Excel, я уверен, что достаточно быстро выучу интуитивный Cypher.

1 Ответ

0 голосов
/ 16 ноября 2018

Во-первых, для небольших данных «песочница» это спорный вопрос.Даже при самом неэффективном расположении данных, если вы избегаете декартовых продуктов и тому подобного, единственное, что вы заметите, это то, насколько интуитивно понятны ваши данные для себя.Так что, если это «игрушечный» масштабный проект, просто сосредоточьтесь на том, что имеет для вас наиболее организационный смысл.Если вы передумаете позже, переформатирование с помощью cypher не будет слишком сложным.


Теперь, предполагая, что это бизнес-проект, который нужно масштабировать до некоторой степени, помните, что неиндексированные свойства в основном невидимыпланировщику Сайфер.Чем более значимы и разнообразны ваши отношения, тем лучше планировщик Cypher будет быстро находить ваши данные.Воспользуйтесь отношениями для соединений, которые вы хотите исследовать, и выберите свойства для данных, которые вы просто хотите увидеть.Индексируйте любые свойства или используйте метки, которые будут ключевыми для поиска определенного (или набора) узлов в ваших запросах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...