Создание иерархического справочника

[r2d2]

День добрый Товарищи! MS DAX 2009. Необходимо реализовать иерархическую таблицу-справочник. Не соображу каким образом указать родителя текущему элементу. Есть мысль добавить поле "Родитель" в таблицу, но каким значением его заполнять было бы правильнее не пойму. Подскажите пожалуйста!

[Logger]

Правильнее было бы его вообще не делать.
Это не в идеологии аксапты.

На форуме обсуждалось.

Цитата:

Сообщение от r2d2

... Есть мысль добавить поле "Родитель" в таблицу, но каким значением его заполнять было бы правильнее не пойму. Подскажите пожалуйста!

Не очень понятно в чем собственно проблема?
Ну добавьте поле родителя и заполняйте его соответствующим идентификатором.

[Ivanhoe]

На форуме обсуждалось, но однозначного вывода я не припомню. В 2012 есть много примеров иерархий. Иерархию категорий продуктов только ленивый не делал для ритейла начиная еще с Axapta 2.5.

Есть конкретные задачи, которые отлично решаются деревом. Есть задачи, которые не решаются. А есть задачи, которые просто не умеет Аксапта, но это не значит, что задача не правильная.

[S.Kuskov]

Цитата:

Сообщение от r2d2

Есть мысль добавить поле "Родитель" в таблицу, но каким значением его заполнять было бы правильнее не пойму. Подскажите пожалуйста!

Значением первичного ключа родительской записи? Или вы о чём-то другом хотели спросить?

[gl00mie]

Если прям очень нужен иерархический справочник, то стоит посмотреть, как реализованы те же категории продуктов (таблица EcoResCategory) в AX2012, в первую очередь с т.з. схемы данных и поддержки дополнительных служебных полей и таблиц:

• ссылка на родительский узел (поле EcoResCategory.ParentCategory) - куда же без нее
• уровень текущего узла (поле Level)
• левые и правые ключи для работы с моделью вложенных множеств (поля NestedSetLeft, NestedSetRight) и логика их обновления - используются для реляционной работы с деревом вместо рекурсивного обхода уровней, см. также Nested Set model
• соответствующие индексы, в т.ч. уникальные

Кроме этого, в AX2012 для Розницы в дереве иерархий могут быть сделаны "исключения", когда иерархические отношения настраиваются не в самом дереве, а в рамках тех или иных акций. Для поддержки таких исключений и упрощения реляционной работы с узлами дерева в модуле Розница есть вспомогательная таблица RetailCategoryContainmentLookup, содержащая все комбинации {узел, родительский узел}, и соотв. логика ее обновления. Также надо обратить внимание на то, что в иерархиях категорий, как и во многих других местах AX2012, первичным ключом записи является RecId, и все ссылки тоже сделаны по RecId.
В таком варианте (ссылки по RecId, модель вложенных множеств) SQL-запросы по категориям работают весьма шустро даже на очень больших и многоуровневых деревьях.

[r2d2]

Цитата:

Сообщение от gl00mie

Если прям очень нужен иерархический справочник, то стоит посмотреть, как реализованы те же категории продуктов (таблица EcoResCategory) в AX2012, в первую очередь с т.з. схемы данных и поддержки дополнительных служебных полей и таблиц:

• ссылка на родительский узел (поле EcoResCategory.ParentCategory) - куда же без нее
• уровень текущего узла (поле Level)
• левые и правые ключи для работы с моделью вложенных множеств (поля NestedSetLeft, NestedSetRight) и логика их обновления - используются для реляционной работы с деревом вместо рекурсивного обхода уровней, см. также Nested Set model
• соответствующие индексы, в т.ч. уникальные

Кроме этого, в AX2012 для Розницы в дереве иерархий могут быть сделаны "исключения", когда иерархические отношения настраиваются не в самом дереве, а в рамках тех или иных акций. Для поддержки таких исключений и упрощения реляционной работы с узлами дерева в модуле Розница есть вспомогательная таблица RetailCategoryContainmentLookup, содержащая все комбинации {узел, родительский узел}, и соотв. логика ее обновления. Также надо обратить внимание на то, что в иерархиях категорий, как и во многих других местах AX2012, первичным ключом записи является RecId, и все ссылки тоже сделаны по RecId.
В таком варианте (ссылки по RecId, модель вложенных множеств) SQL-запросы по категориям работают весьма шустро даже на очень больших и многоуровневых деревьях.

У меня DAX 2009. Не знаю, применимо ли вами сказанное к ней. Но общую мысль уловил.

[r2d2]

Цитата:

Сообщение от S.Kuskov

Значением первичного ключа родительской записи? Или вы о чём-то другом хотели спросить?

Да именно это и хотел спросить. Спасибо. Вопрос еще и в целом по методологии, правильно ли так делать.

[Ivanhoe]

Чтобы обсудить "методологию" нужна постановка задачи. Что нужно решить, как вы считаете, деревом?

[r2d2]

Цитата:

Сообщение от Ivanhoe

Чтобы обсудить "методологию" нужна постановка задачи. Что нужно решить, как вы считаете, деревом?

Необходимо создать таблицу настроек ,которая воспроизводит воспроизвести иерархию подразделений предприятия, с 3 уровенями вложенности. В дальнейшем по этой таблице будет строиться отчет. К данным подразделениям хочу "привязать" центры фин. ответственности(ЦФО), в разрезе которых и хранятся суммовые данные. ИТОГО: данные хранятся в разрезе ЦФО, отчет должен строится по подразделеням ,которых в Аксапте нет. Цель создания таблицы - построение соответствия между ЦФО и подразделениями.

[Ruff]

Цитата:

Сообщение от r2d2

ИТОГО: данные хранятся в разрезе ЦФО, отчет должен строится по подразделеням ,которых в Аксапте нет. Цель создания таблицы - построение соответствия между ЦФО и подразделениями.

Посмотрите форму HRPPartyOrganizationUnit и вообще таблицы DirParty***
Если по каким-то причинам не устраивает стандарт, для ваших узких целей дешевле будет сделать три отдельные таблицы (например, Подразделения, Департаменты, Отделы) и связать их иерархически:

Подразделения -> Департаменты (1:N)
Департаменты -> Отделы (1:N)
Отделы -> ЦФО (1:1)

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