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

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

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]

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

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


neo4j graph-databases datomic
person ForeverConfused    schedule 21.03.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

[ОТРЕДАКТИРОВАНО]

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

Вы можете использовать узел для каждого вопроса опроса и присвоить всем этим узлам одну и ту же метку, например 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;

Чтобы получить клиентов, которые дали каждый ответ на вопрос (это чувствительно к регистру, поэтому вы можете захотеть перевести все ответы в нижний регистр, используя LOWER перед сохранением их в отношениях 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;
person cybersam    schedule 21.03.2016

arrow_upward
1
arrow_downward

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

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

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

person Evgen    schedule 21.03.2016