AXForum  
Вернуться   AXForum > Прочие обсуждения > forum.mazzy.ru > Обсуждение статей на mazzy.ru
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 08.09.2004, 20:58   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Вопрос «как сделать иерархический справочник», «может ли Аксапта работать с древовидными справочниками», «как работать с tree» настолько часто задается, настолько часто обсуждается, что я решил написать на эту тему статью и совет. Статья отражает мое личное мнение по поводу иерархий. В совете будет пример правильной (на мой взгляд) реализации иерархических справочников в Аксапте.

Иерархический справочник и Axapta. Часть 1: Размышления
http://axapta.mazzy.ru/articles/tree/
__________________
полезное на axForum, github, vk, coub.
Старый 09.09.2004, 10:23   #2  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Мда, эта тема актуальна и для Навижина. Основная проблема - поддержка визуального отображения "деревянной" структуры. Навижин не поддерживает встраиваемые визуальные объекты, а Аксапта? Но народ исхитрился конечно - сделал на том, что есть.
Старый 09.09.2004, 14:22   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
поддерживает.
но лучше бы не поддерживала...

представление в виде дерева (treeview) приводит либо к огромному программированию, либо к очень неэффективной и медленной работе. Об этом будет следующий совет.
__________________
полезное на axForum, github, vk, coub.
Старый 09.09.2004, 15:01   #4  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
В мою бытность программирования на Дельфи, мы, своей компанией, разработали компонент для этого + скрипты для ErWin для генерации серверного кода "деревянной" структуры, все работало через хранимые процедуры и очень быстро и весело. Что мешает это же сделать в Аксапте? Я не знаком с программированием в ней, но по слухам там все весьма объектно и доступно. Всего-то нужно: визуальный компонент дерева с эвентами и возможность связать его с данными из хранимых процедур.
Старый 09.09.2004, 23:40   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
дерево нельзя получить одним запросом или приходится мучатся.
итоги по элементам и группам одновременно вообще нельзя получить одним запросом.
Только если дублировать проводки и по элементу и по группе.

В общем-то я специально сделал паузу перед технической частью, чтобы была возможность подумать.
__________________
полезное на axForum, github, vk, coub.
Старый 10.09.2004, 10:57   #6  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
А никто и не говорит про один запрос ;-)
Фактически должно быть два запроса: открыть дерево (верхний уровень) и открыть ветку. А вот результат второго запроса "деревянный" компонент должен уметь обработать и это самое засадное.
Старый 10.09.2004, 15:52   #7  
mpa is offline
mpa
Участник
 
64 / 12 (1) ++
Регистрация: 26.01.2002
Адрес: Москва - Нижний Новгород
Цитата:
Сообщение от mazzy
В общем-то я специально сделал паузу перед технической частью, чтобы была возможность подумать.
А задуматься действительно есть над чем.

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

К несчастью, переубедить не удавалось и "дерево" реализовывали. Правда через пару месяцев про "дерево" благополучно забывали и не пользовали. А вот группировки по Ном.группам, Группам закупщиков и т.п. приживались.
Старый 10.09.2004, 17:19   #8  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Я так понял, что стоит вопрос "можно-нельзя", а не "нужно-ненужно".
Очень часто для Заказчика бантик важнее функционала. Тут же разница примерно как между Виндовс Экплорером и оболочкой ФАР (аля Нортон). Я вот лично не люблю Экплорер с деревом и пользуюсь ФАРом, а кто-то наоборот.
Старый 14.09.2004, 13:53   #9  
Владимир Максимов_imported is offline
Владимир Максимов_imported
Участник
 
33 / 10 (1) +
Регистрация: 20.01.2004
Цитата:
Сообщение от Dzemon
Я так понял, что стоит вопрос "можно-нельзя", а не "нужно-ненужно".
Нет. Здесь вопрос как раз-таки ставится "нужно-не нужно". То что это сделать "можно", даже не обсуждается. Делают же

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

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

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

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

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

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

Аргументация идет примерно такая же, что и в отношении использования дерева - а я так привык, зачем мне переучиваться?
Старый 14.09.2004, 15:19   #10  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
590 / 49 (3) +++
Регистрация: 11.06.2003
Адрес: Москва
"Я так привык" Вы не относите к "логическим аргументам" ? а вот я бы сначала подумал ! мне кажется, что во многих случаях - это весьма сильный и логичный аргумент. Потому что "пользователь" - от слова "пользоваться". Пользоваться бывает "удобно" или "неудобно", и это тоже весьма субъективный критерий, как и "привык-не привык".

Возвращаясь к любимой-нелюбимой многими аналогии с машинами: выбор машины с правым или левым рулем. Например, если вы никогда не идете на рискованные обгоны, то лучший обзор встречной полосы для вас не так критичен, зато удобно выходить из машины сразу на тротуар, а не на проезжую часть. И это логичный аргумент "за". Но если Вы привыкли (!) ездить с левым рулем, то переход на правый может не просто превратить езду из удовольствия в кошмар, но и привести к аварии (возможно, и не одной). Так что в данном случае привычка - сильнейший и логичнейший аргумент. Поскольку вы работаете с системой УПРАВЛЕНИЯ, (автомобилем вы тоже управляете), то неудобство в работе управления бизнеса может привести к реальным потерям. И неизвестно еще, привыкните ли вы к другой модели работы (=управления), навязанной вам с вполне логичными аргументами.
Старый 14.09.2004, 17:01   #11  
Владимир Максимов_imported is offline
Владимир Максимов_imported
Участник
 
33 / 10 (1) +
Регистрация: 20.01.2004
Цитата:
Сообщение от Тренер
Возвращаясь к любимой-нелюбимой многими аналогии с машинами: выбор машины с правым или левым рулем. 
С аналогиями надо бы поосторожнее. Если бы системой AXAPTA пользовался исключительно один пользователь (как машиной), то Вы абсолютно правы.

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

Собственно об этом mazzy и написал: Собака, конечно, друг, но одного человека. То же самое и с деревом.
Старый 14.09.2004, 17:28   #12  
ТРЕНЕР is offline
ТРЕНЕР
Участник
Аватар для ТРЕНЕР
 
590 / 49 (3) +++
Регистрация: 11.06.2003
Адрес: Москва
Если система предоставяет возможность настройки интерфейса под разных пользователей, нужно этим пользоваться, чтобы сделать работу ПРИВЫЧНЕЕ, а значит и удобнее, а переход на новую систему - НАМНОГО более легким.

Если такой возможности нет, надо
а) быстро сделать такие возможности там, где это возможно сделать быстро,
б) взвесить соотношение критичности и трудоемкости реализации там, где это сделать быстро нельзя, и спланировать выполнение наиболее критичных
Иерархия очевидно подпадает под пункт б).
Старый 14.09.2004, 18:23   #13  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Согласен с Тренер

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

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

По поводу RecordSet. Вобщем типичная ошибка, связанная с непониманием идеи SQL. Да она часто повторяется в стремлении выплюнуть 100000 записей в один несчастный Grid. Ведь пользователю из всего этого списка наверняка нужны десяток строк. Вот построение системы удобной фильтрации для минимизации потока информации и есть задача Деревьев и Фильтров.
Старый 15.09.2004, 10:07   #14  
Владимир Максимов_imported is offline
Владимир Максимов_imported
Участник
 
33 / 10 (1) +
Регистрация: 20.01.2004
Хм... Ответы опять крутятся вокруг "можно - нельзя". Mazzy ведь пытается сказать, что дерево не облегчает, а усложняет работу с программой.

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

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

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

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

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

Причем, заметьте, кончается такое "хотение" обычно тем, что пользователь "забывает" про дерево, поскольку есть более удобный способ поиска данных. В 1C не может забыть, поскольку нет альтернативы.
Старый 15.09.2004, 10:18   #15  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов
В 1C не может забыть, поскольку нет альтернативы.
Да, Владимир.

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

Если кто работал с 1С... Вспомните, что говорил Сергей Нуралиев по поводу фильтрации в справочниках. Отсутствие фильтрации - это не недочет в проектировании - это было осознанное решение. И для небольших справочников это было правильным решением.
__________________
полезное на axForum, github, vk, coub.
Старый 15.09.2004, 10:19   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
часть 2 будет опубликована в эти выходные.
__________________
полезное на axForum, github, vk, coub.
Старый 16.09.2004, 14:44   #17  
AxMonster is offline
AxMonster
Участник
 
8 / 10 (1) +
Регистрация: 19.07.2004
Цитата:
Сообщение от Владимир Максимов
-) Несмотря на то, что дерево призвано облегчить поиск на самом деле оно его затрудняет (найти в дереве нужный элемент новичку, не знакомому с его структурой - проблематично; если условиям поиска удовлетворяют несколько узлов из разных веток - несколько поисков вместо одного)
Давайте посмотрим с другой стороны: со сложными справочниками (номенклатуры) работают специалисты. Специалист должен знать группировку своих номенклатур.
Я имею ввиду иерархические справочники ТНВЭД, ГОСТ, отраслевые классификаторы и т.д.

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

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

Т.е. в бизнесе группировки и иерархии нас преследуют на каждом шагу (ГОСТ, ТНВЭД) и нужно решить порос их оптимальной реализации.
__________________
AxMonster Group
axmonster@axmonster.com
Старый 16.09.2004, 15:41   #18  
Захаров Александр is offline
Захаров Александр
Работодатель
 
68 / 12 (1) ++
Регистрация: 04.12.2003
Адрес: Москва

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

С горячим египетским приветом ...
Старый 16.09.2004, 22:40   #19  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Захаров Александр
С горячим египетским приветом ...
Спасибо, до сих пор спина облазит.

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

С не менее горячим приветом...
__________________
полезное на axForum, github, vk, coub.
Старый 17.09.2004, 10:53   #20  
Захаров Александр is offline
Захаров Александр
Работодатель
 
68 / 12 (1) ++
Регистрация: 04.12.2003
Адрес: Москва
У меня, например, строится дом. В секцию <входят> 17 этажей, в этаж 4 квартиры, в квартиру ... Это не справочник? Это иерархия?
 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:53.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.