Иерархический справочник и Axapta.

[mazzy]

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

Иерархический справочник и Axapta. Часть 1: Размышления
http://axapta.mazzy.ru/articles/tree/

[Dzemon]

Мда, эта тема актуальна и для Навижина. Основная проблема - поддержка визуального отображения "деревянной" структуры. Навижин не поддерживает встраиваемые визуальные объекты, а Аксапта? Но народ исхитрился конечно - сделал на том, что есть.

[mazzy]

поддерживает.
но лучше бы не поддерживала...

представление в виде дерева (treeview) приводит либо к огромному программированию, либо к очень неэффективной и медленной работе. Об этом будет следующий совет.

[Dzemon]

В мою бытность программирования на Дельфи, мы, своей компанией, разработали компонент для этого + скрипты для ErWin для генерации серверного кода "деревянной" структуры, все работало через хранимые процедуры и очень быстро и весело. Что мешает это же сделать в Аксапте? Я не знаком с программированием в ней, но по слухам там все весьма объектно и доступно. Всего-то нужно: визуальный компонент дерева с эвентами и возможность связать его с данными из хранимых процедур.

[mazzy]

дерево нельзя получить одним запросом или приходится мучатся.
итоги по элементам и группам одновременно вообще нельзя получить одним запросом.
Только если дублировать проводки и по элементу и по группе.

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

[Dzemon]

А никто и не говорит про один запрос ;-)
Фактически должно быть два запроса: открыть дерево (верхний уровень) и открыть ветку. А вот результат второго запроса "деревянный" компонент должен уметь обработать и это самое засадное.

[mpa]

Цитата:

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

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

А задуматься действительно есть над чем.

Лирика:
На нескольких проектах заказчику было "ЖИЗНЕННО НЕОБХОДИМО", чтобы было реализовано "дерево" для справочника номенклатуры, поскольку этот древовидный справочник был рожден ими в муках в течении многих лет.

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

[Dzemon]

Я так понял, что стоит вопрос "можно-нельзя", а не "нужно-ненужно".
Очень часто для Заказчика бантик важнее функционала. Тут же разница примерно как между Виндовс Экплорером и оболочкой ФАР (аля Нортон). Я вот лично не люблю Экплорер с деревом и пользуюсь ФАРом, а кто-то наоборот.

[Владимир Максимов_imported]

Цитата:

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

Я так понял, что стоит вопрос "можно-нельзя", а не "нужно-ненужно".

Нет. Здесь вопрос как раз-таки ставится "нужно-не нужно". То что это сделать "можно", даже не обсуждается. Делают же

Цитата:

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

Очень часто для Заказчика бантик важнее функционала. Тут же разница примерно как между Виндовс Экплорером и оболочкой ФАР (аля Нортон). Я вот лично не люблю Экплорер с деревом и пользуюсь ФАРом, а кто-то наоборот.

Мне кажется, что это вопрос из разряда "а я привык работать вот так". Никакими логическими аргументами здесь ничего не докажешь.

Чтобы понять все проблемы работы с деревьями надо не просто разок попробовать реализовать эту концепцию, но и время от времени возвращаться к сделанной реализации и смотреть на нее с позиции нового опыта.

В конференции часто возникают сообщения вроде "мы реализовали дерево" или "реализую за 40 минут". Но почему-то никто не сравнивает эффективность работы с деревом по сравнению с обычными фильтрами. Т.е. мало кто вспоминает собственные ошибки.

Небольшое отступление (не смог удержаться )

Я время от времени посещаю конференцию по FoxPro и там возникают вопросы от программистов, которые раньше программировали на Delphi вроде такого: как "прикрутить" ADO.RecordSet к Grid?

Не то, чтобы это было в принципе невозможно, но это сопряжено с большими проблемами. А основная сложность заключается в том, что доказать такому человеку ошибочность самой идеи такого подхода (т.е. что ADO.RecordSet вообще не стоит использовать в FoxPro) практически невозможно!

Аргументация идет примерно такая же, что и в отношении использования дерева - а я так привык, зачем мне переучиваться?

[ТРЕНЕР]

"Я так привык" Вы не относите к "логическим аргументам" ? а вот я бы сначала подумал ! мне кажется, что во многих случаях - это весьма сильный и логичный аргумент. Потому что "пользователь" - от слова "пользоваться". Пользоваться бывает "удобно" или "неудобно", и это тоже весьма субъективный критерий, как и "привык-не привык".

Возвращаясь к любимой-нелюбимой многими аналогии с машинами: выбор машины с правым или левым рулем. Например, если вы никогда не идете на рискованные обгоны, то лучший обзор встречной полосы для вас не так критичен, зато удобно выходить из машины сразу на тротуар, а не на проезжую часть. И это логичный аргумент "за". Но если Вы привыкли (!) ездить с левым рулем, то переход на правый может не просто превратить езду из удовольствия в кошмар, но и привести к аварии (возможно, и не одной). Так что в данном случае привычка - сильнейший и логичнейший аргумент. Поскольку вы работаете с системой УПРАВЛЕНИЯ, (автомобилем вы тоже управляете), то неудобство в работе управления бизнеса может привести к реальным потерям. И неизвестно еще, привыкните ли вы к другой модели работы (=управления), навязанной вам с вполне логичными аргументами.

[Владимир Максимов_imported]

Цитата:

Сообщение от Тренер

Возвращаясь к любимой-нелюбимой многими аналогии с машинами: выбор машины с правым или левым рулем. 

С аналогиями надо бы поосторожнее. Если бы системой AXAPTA пользовался исключительно один пользователь (как машиной), то Вы абсолютно правы.

Проблема только в том, что одной и той же системой пользуется очень много народа. Возвращаясь к Вашей аналогии. Пусть начальник привык ездить с правым рулем. Дал порулить подчиненному (случилось чудо ) - немедленная авария.

Собственно об этом mazzy и написал: Собака, конечно, друг, но одного человека. То же самое и с деревом.

[ТРЕНЕР]

Если система предоставяет возможность настройки интерфейса под разных пользователей, нужно этим пользоваться, чтобы сделать работу ПРИВЫЧНЕЕ, а значит и удобнее, а переход на новую систему - НАМНОГО более легким.

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

[Dzemon]

Согласен с Тренер

Только два замечания: переделка интерфейса - штука трудоемкая и неблагодарная, вас могут попросить сделать 1С из Аксапты; при значительном изменении интерфейса, уже через полгода, при возникновении проблемы, можно долго выяснять - в какой же программе работает пользователь?

По поводу дерева. Я думаю вопрос даже не поднимался, если бы его можно было сделать с полпинка ;-) Я прекрасно знаю о всех "деревянных" проблемах и сколько ресурсов оно лопает. Но для пользователя это зачастую показатель современности системы! С другой стороны, огромное, не помещающееся на экране дерево жизни не облегчает, ничто так не разражает как скроллинг в дереве (ну может и придираюсь). В этом случае гораздо удобнее пользоваться последовательной фильтрацией (это эквивалент перебора каталогов в Нортоне ;-)). Единственное условие - отображать набор примененных фильтров.

По поводу RecordSet. Вобщем типичная ошибка, связанная с непониманием идеи SQL. Да она часто повторяется в стремлении выплюнуть 100000 записей в один несчастный Grid. Ведь пользователю из всего этого списка наверняка нужны десяток строк. Вот построение системы удобной фильтрации для минимизации потока информации и есть задача Деревьев и Фильтров.

[Владимир Максимов_imported]

Хм... Ответы опять крутятся вокруг "можно - нельзя". Mazzy ведь пытается сказать, что дерево не облегчает, а усложняет работу с программой.

Я не буду повторять аргументы mazzy из его статьи. Просто хочу спросить, у Вас есть что возразить по следующим тезисам:

-) Дерево всегда настраивается под одного пользователя, что неприемлимо при работе в многопользовательской системе - конфликты неизбежны (не могу найти, ввод дублей и т.п.)

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

Заметьте, это вопросы не конкретной реализации (программирования), а именно процесса работы. Т.е. из разряда: а нужно ли оно нам вообще?

Пока аргументы "ЗА" вертятся вокруг одного: а пользователь так хочет!

Причем, заметьте, кончается такое "хотение" обычно тем, что пользователь "забывает" про дерево, поскольку есть более удобный способ поиска данных. В 1C не может забыть, поскольку нет альтернативы.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

В 1C не может забыть, поскольку нет альтернативы.

Да, Владимир.

Я очень хотел обойти этот пункт стороной.
Но. Вспомните почему дерево так популярно в 1С.
В версиях 2.0 Проф, 6.0, 7.0, 7.5, 7.7 ФИЗИЧЕСКИ не было возможности отфильтровать записи в справочнике по реквизиту. Поэтому оставалась только одна штатная возможность фильтрации - разместить в группах.

Если кто работал с 1С... Вспомните, что говорил Сергей Нуралиев по поводу фильтрации в справочниках. Отсутствие фильтрации - это не недочет в проектировании - это было осознанное решение. И для небольших справочников это было правильным решением.

[mazzy]

часть 2 будет опубликована в эти выходные.

[AxMonster]

Цитата:

Сообщение от Владимир Максимов

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

Давайте посмотрим с другой стороны: со сложными справочниками (номенклатуры) работают специалисты. Специалист должен знать группировку своих номенклатур.
Я имею ввиду иерархические справочники ТНВЭД, ГОСТ, отраслевые классификаторы и т.д.

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

Если говорить о "чайниках" то для этого в Axapta имеется отдельный иерархический справочник для пользователей CG.

Т.е. в бизнесе группировки и иерархии нас преследуют на каждом шагу (ГОСТ, ТНВЭД) и нужно решить порос их оптимальной реализации.

[Захаров Александр]

Цитата:

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

Не только.
Иерархия нужна там, где будем строить аналитику. Например статьи затрат, или вхождение элементов друг в друга.

С горячим египетским приветом ...

[mazzy]

Цитата:

Сообщение от Захаров Александр

С горячим египетским приветом ...

Спасибо, до сих пор спина облазит.

насчет статей затрат, аналитик и иерархий - не понял.

С не менее горячим приветом...

[Захаров Александр]

У меня, например, строится дом. В секцию <входят> 17 этажей, в этаж 4 квартиры, в квартиру ... Это не справочник? Это иерархия?