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

Question

Я собираюсь использовать эту концепцию в одном из моих будущих проектов.

Подробнее: Управление иерархическими данными в MySQL .

Пожалуйста, поделитесь своим опытом, хорошим или плохим, с примерами.

Я добавляю больше информации, чтобы сделать ее более широкой:

У меня есть дочерние элементы, которые могут иметь более одного родителя (например, пользователь может принадлежать городу, а также группе с именем UserDefinedRegion), которую типичные иерархические модели не поддерживают, будь то список смежности или вложенные множества.

Я вставил здесь пример использования для ясности:

---

Справочная информация. В настоящее время в системе установлена ​​фиксированная иерархия: штат-> округ-> город-> пользователь

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

2. Менеджер по продажам входит в систему и создает новую группу, которая может находиться между штатом и округом или округом и городом.

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

---

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

До настоящего времени пользователи stackOverflow предлагали следующие решения:

1. Структура сетевого узла, поддерживаемая сетевой базой данных.
2. Направленные ациклические графы.

Я определенно ищу решение СУБД. Похоже, в реальной жизни немногие сталкивались с несколькими родительскими узлами в иерархических моделях данных.

Answer 1

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

Если вы все еще хотите туда поехать, я бы назвал это сетевой структурой узлов. Вот ссылка .

Answer 2

Поскольку вы, вероятно, будете использовать хранимые процедуры для некоторых операций, убедитесь, что они действительно работают достаточно хорошо для ваших нужд! Это может быть проблемой, если вы используете MySQL, по моему опыту.

Относительно нового требования (несколько родителей): теперь вы используете гораздо более проблемные вещи при использовании СУБД, в зависимости от того, какие запросы вам нужно выполнить для данных. Я сравнил подход RDBMS к использованию графической базы данных на этой вики-странице . Если вас интересует только подход RDBMS, взгляните на Модель для представления направленных ациклических графов (DAG) в базах данных SQL .