Каков наилучший способ моделирования определяемых пользователем иерархических отношений в базе данных?
-
05-09-2019 - |
Вопрос
По сути, я хочу, чтобы пользователь мог определить иерархическую модель, но затем мне нужно разрешить пользователю хранить данные в рамках определенной модели.Имеет ли это смысл?Таким образом, пользователи смогут создавать новые «типы юнитов», которые будут организованы иерархически, и решать, как можно организовывать юниты этих типов.Простой пример:в моем гипотетическом интерфейсе пользователь создает три типа модулей: ствол, ветвь и лист.Затем пользователь определяет отношения между ними.Лист может существовать в любой точке иерархии, ветвь должна иметь ствол в качестве родителя.Затем пользователь может создавать экземпляры этих типов единиц (как единицы) и организовывать их в соответствии с правилами, определенными в их модели...есть ли хороший способ сделать это в базе данных?
Решение
Это чрезвычайно широкий вопрос, но он может указать вам правильное направление.Обратите внимание, что вы сможете хранить только правила отношений в базе данных.Их соблюдение будет зависеть от вашего клиентского кода.Примерьте это на размер..
unit:
unit id,
name,
unit relationship:
unit id,
foreign unit id
Затем вы можете использовать таблицу отношений единиц следующим образом.
unit id
относится к единице, которую он описывает.foreign unit id
должно быть обнуляемым.
А unit
без записей о взаимоотношениях может существовать только в корне иерархии.А unit
с null
foreign unit id
может быть любой другой unit
как его родитель.В противном случае unit
должен быть другой unit
в качестве его родителя, и его тип должен быть одним из тех, которые определены в его записях отношений.
Что касается хранения самих экземпляров, это должно быть просто.
instance:
instance id,
unit id,
parent instance_id
Я уверен, что вам понадобятся и другие поля (например, имя), но я предполагаю, что вы поняли суть.
Другие советы
Вам необходимо реализовать три концепции:
- «типы единиц» и их разрешенные ассоциации
- иерархия
- фактические единицы
Эти концепции могут сосуществовать в модели более или менее независимо, но работать вместе.
create table unittype
(
id int;
name varchar(20);
)
create table unitrelationship
(
id int;
parent_id int;
)
Вы можете смоделировать иерархию как самоссылающуюся таблицу:
create table hierarchy
(
id int;
parent_id int;
unit_type_id int;
unit_id int;
)
Затем вы можете разместить экземпляры своих модулей в одной или нескольких таблицах и делать с ними то, что вы описали.
create table unit
{
id int;
....
}
Хорошей новостью является то, что вы ограничиваете только разрешенные родительские типы, что можно легко реализовать в пользовательском интерфейсе, например, выбрав родительский элемент из списка всех существующих модулей разрешенного типа.
Я работаю над аналогичной проблемой, хотя мне нужно поддерживать несколько иерархий (один набор дочерних элементов, несколько иерархических представлений).Я нашел книгу Джо Селко «Деревья и иерархии в SQL для умников» (ISBN:1558609202) пригодится.Я все еще работаю над этой проблемой, но при обсуждении этой темы она возникает так часто, что кажется уместным упомянуть.