Я прошу указать плюсы и минусы тех решений, которые я предложил для решения задачи, описанной ниже. Подробное описание внутренних компонентов neo4j, таких как хранение и обработка, приветствуется. Я был бы признателен за то, что обратился к пунктам, например U.2 / A.1.A для четкого различия.
Я разрабатывал модель, в которой у нас есть два типа действующих лиц: Пользователь и Администратор.
Пользователь системы может:
- U.1) перечислить как действительные, так и недействительные (выданные или отозванные) приглашения с нумерацией страниц
- U. 2) выдать приглашение (для других незарегистрированных лиц),
- U.3) отозвать приглашение (в любой момент),
Администратор системы, получив идентификатор приглашения, может:
- A.1) перечислить как действительные, так и недействительные приглашения в системе и найти узел приглашения по его идентификатору
- A.2) определить, какой пользователь выдал / отозвал приглашение по его заданному идентификатору
Так что мне пришла в голову идея, где узел приглашения хранит такие свойства, как:
Пояснения к приведенные ниже графики:
- Зеленый кружок представляет выданный узел приглашения
- Красный кружок представляет аннулированный узел приглашения
- Зеленые пунктирные линии представляют новые отношения, которые будут созданы
- Красные прямые линии представляют предыдущее отношение, которое будет удалено
U.1)
U.2)
U.3)
A.1) Теперь часть администратора, где он получает идентификатор приглашения (например, INV_ID_2), по которому ищется узел приглашения (желтый узел) Три различных решения: A.1.A) Чтобы ускорить поиск, я подумал о том, чтобы дать еще один уникальный ярлык узлу приглашения, который будет обозначать сам идентификатор - INV_ID_2
A.1.B) добавление нового узла AllInvitations (синего цвета) и установка уникальных отношений между ним и каждым узлом Приглашения. Чтобы найти INV_ID_2, мы должны go просмотреть список его отношений.
A.1. C) сохранить идентификатор как индексированное свойство на узле приглашения - в данном случае имя свойства ID со значением INV_ID_2
A.1.A)
A.1. B)
A.1. C)
A.2) Принимая во внимание решения сверху при присвоении идентификатора приглашения (желтый узел), чтобы определить, к какому пользователю он привязан, нам придется Пройдите по графику с помощью ПРЕДЫДУЩИХ и (IN) ДЕЙСТВИТЕЛЬНЫХ отношений (желтого цвета), пока мы не доберемся до узла UserInvitations. Более быстрым решением будет добавление прямой связи BOUND_TO (синего цвета) между каждым узлом Invitation и UserInvitations. Однако это состоит из множества отношений, которые необходимо поддерживать.
Имея все это в виду, я подумал о другом решении, в котором мы оставляем Пользователя и связанные с ним Подробности приглашений в прямой ссылке.
Но теперь я возвращаюсь к исходной точке - как отличить guish VALID от INVALID приглашений а также добавить нумерацию страниц? У нас есть много вариантов, таких как:
- A) добавление отношений даты, таких как DATE_2020_01_13 и VALID / INVALID
- B) объединение отношений из точки A в одну, например, VALID_2020_01_13
- C) добавление свойств к самому отношению
- D) и т. Д. ...
Это могло бы повлиять на разбиение на страницы данных, например, для поиска 10 последних VALID-приглашений для конкретного пользователя всегда требуется отправка через все отношения и сортировку по дате.
Интересно, как это влияет на производительность и какой подход может быть лучше, чем те, что представлены выше?
Я хотел бы отметить, что я ладья ie, работаю с Neo4j. Я читал кое-что о различных подходах к дизайну, производительности и внутреннем оборудовании. Однако я нашел статьи или книги (базы данных графиков), связанные с внутренними данными о том, как все хранится в файлах, а затем обрабатываются без какой-либо важной информации, чтобы я мог получить полную картину. Поэтому я прошу пролить некоторый свет на эту тему c и не опускаю детали, дающие объяснения.