Как мне моделировать опросы клиентов в графической базе данных?

Question

Наша компания имеет много данных о клиентах, основанных на опросах. Например, мы можем знать, что кому-то нравится какой-то вид спорта, телешоу, какая-то группа, он беременен и находится в каком-то возрастном диапазоне. Маркетологи будут добавлять и удалять критерии для отслеживания. Графовые базы данных предлагают различные варианты моделирования, например, мы можем сделать что-то вроде моделирования объектов

Customer.survey_question1.question = "What tv show do you like"
Customer.survey_question1.answer = "Sesame street"

Здесь мы дадим клиенту свойство со ссылкой на вопрос 1 опроса, который будет содержать свойства опроса. Каждый раз, когда маркетологи добавляют вопрос и ответ, мы должны обновить схему клиента.

Мы могли бы также смоделировать это так

Customer.surveys = [list of references to other objects]

Где опросы - это список ссылок на опрашиваемые объекты, на которые они ответили.

Что такое идиоматический способ добавить очень разреженный список свойств клиентов в graphdb

Answer 1

[EDITED]

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

Вы можете использовать узел для каждого вопроса опроса и дать всем этим узлам одну и ту же метку, скажем SurveyQuestion, Например:

(sq:SurveyQuestion {id: 222, question: "What tv show do you like?"})

Каждый клиент, который отвечает на SurveyQuestion может иметь отношения определенного типа (скажем, ANSWERED) к узлу этого вопроса, и это отношение может содержать ответ человека. Например:

(:Customer {id:123})-[:ANSWERED {answer: "The Voice"}]->(sq)

При таком подходе нет необходимости обновлять Customer узел, когда вы добавили новый вопрос опроса. Вам нужно только создать ANSWERED отношения, когда клиент фактически отвечает на вопрос.

Чтобы получить все вопросы опроса:

MATCH (sq:SurveyQuestion)
RETURN sq;

Чтобы получить клиентов, которые дали каждый ответ на вопрос (это чувствительно к регистру, поэтому вы можете захотеть использовать строчные буквы в нижнем регистре, прежде чем сохранять их в ANSWERED отношения):

MATCH (sq:SurveyQuestion {id: 222})<-[a:ANSWERED]-(c:Customer)
RETURN sq, a.answer AS answer, COLLECT(c);

Чтобы получить ответы на все вопросы клиента и свой ответ на каждый из них:

MATCH (sq:SurveyQuestion)<-[a:ANSWERED]-(c:Customer {id: 123})
RETURN c, a.answer AS answer, sq;

Answer 2

Из моего опыта (около ~1 года с neo4j). Самое большое преимущество граф-баз данных в качестве хранилища данных - это сложное понимание их существующих данных (где базы данных SQL с таблицей соединений имеют низкую производительность). Таким образом, хранение всех данных, извлеченных из опроса в узле Customer или (:Customer)-[:ANSWERS]->(:Servey), не дает никаких преимуществ от базы данных neo4j. Но у вас есть некоторые "темные стороны" neo4j:) Я не говорю, что neo4j плох, но в настоящее время он не так отполирован, как sql. Таким образом, чтобы получить преимущество от neo4j, я бы попытался сохранить каждый пользовательский ответ как отдельную сущность, если она имеет смысл. Создание узлов, таких как: Спорт,:TvShow. Но возраст, в котором я хотел бы хранить данные: Клиент - это дата его рождения. Или вы можете сгенерировать дерево Календаря, если планируете использовать его и в других случаях. Таким образом, вы можете сохранить дату рождения как отношение к определенному узлу дерева календаря (: День или: Месяц или Год и т. Д.).

Я бы использовал модель как(c:Customer)-[r1:ANSWERS]->(s:Servey), (c)-[r2:WATCHES]->(tv:TvShow), (s)-[:SERVEY_REPLY]->(tv), Поэтому, когда клиент меняет свое мнение и перестает смотреть шоу, я удаляю отношение r1, но я не теряю данные, поскольку они сохранили его r2. Вы можете добавить к этой модели отношения: Календарь и много разных сотрудников, но будьте уверены, что вам это нужно).

PS Насколько я знаю, есть некоторые высокооплачиваемые люди для моделирования баз данных:) Мой совет, если вы не уверены, что получаете выгоду от граф-базы данных, чем не использовать ее на производстве:)