Каков наилучший способ моделирования пользовательских иерархических отношений в базе данных? - PullRequest
Новая
       30

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

3 голосов
/ 08 апреля 2009

По сути, я хочу, чтобы пользователь мог определять иерархическую модель, но затем мне нужно разрешить пользователю хранить данные в пределах своей определенной модели. Имеет ли это смысл? Таким образом, пользователи смогут создавать новые «типы юнитов», которые будут организованы иерархически, и решать, каким образом юнитам этих типов разрешено организовываться. Простой пример: в моем гипотетическом интерфейсе пользователь создает три типа юнитов: транк, ветвь и лист. Затем пользователь определяет отношения между ними. Лист может существовать в любой точке иерархии, ветвь должна иметь ствол в качестве родителя. Затем пользователь может создавать экземпляры этих типов единиц (как единицы) и организовывать их в соответствии с правилами, определенными в их модели ... Есть ли хороший способ сделать это в базе данных?

Ответы [ 3 ]

3 голосов
/ 08 апреля 2009

Это чрезвычайно широкий вопрос, но он может указать вам правильное направление. Обратите внимание, что вы только сможете хранить правила отношений в базе данных. Их применение будет зависеть от кода вашего клиента. Попробуйте это для размера .. 

unit:
    unit id,
    name,

unit relationship:
    unit id,
    foreign unit id

Затем вы можете использовать свою таблицу отношений юнитов следующим образом.

unit id относится к описываемой единице. foreign unit id должен быть обнуляемым.

A unit без записей отношений может существовать только в корне иерархии. unit с null foreign unit id может иметь любой другой unit в качестве родителя. В противном случае unit должен иметь другого unit в качестве своего родителя, и его тип должен быть одним из тех, которые определены в его записях отношений.

Что касается хранения самих экземпляров, это должно быть просто .. 

instance:
    instance id,
    unit id,
    parent instance_id

Я уверен, что вам понадобятся другие поля (например, имя), но я предполагаю, что вы получите дрейф.

2 голосов
/ 08 апреля 2009

Вам необходимо реализовать три понятия:

  • «типы единиц» и их разрешенные ассоциации
  • иерархия
  • фактические единицы

Эти концепции могут более или менее сосуществовать в модели независимо, но работать вместе. 

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;
    ....
}

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

1 голос
/ 10 сентября 2009

Я работаю над аналогичной проблемой, хотя мне нужно поддерживать несколько иерархий (один набор дочерних элементов, несколько иерархических представлений). Я нашел полезными Джо Селко «Деревья и иерархии в SQL для умников» (ISBN: 1558609202). Я все еще работаю над этой проблемой, но при обсуждении этой темы она возникает так часто, что мне кажется уместным упомянуть.

...