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

[mazzy]

Это обычная реляционная (плоская) таблица.
Хотя можно эти данные представить и в виде иерархии.

Но если вы работаете на реляционной СУБД (!), вам эффективнее представить эти данные как реляционную таблицу

[Dzemon]

Цитата:

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

Это обычная реляционная (плоская) таблица.
Хотя можно эти данные представить и в виде иерархии.

Но если вы работаете на реляционной СУБД (!), вам эффективнее представить эти данные как реляционную таблицу

Ээээээээ......... А иерархия это не плоская таблица?

[mazzy]

нет.

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

Не буду вмешиваться в умный спор, но видеть мне ее понятее в виде дерева.

[mazzy]

да. обратите внимание на слово "видеть".
видеть и хранить - разные вещи.

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

Потому и не вмешиваюсь, но если только видеть ..., хранить тоже, повидимому, надо правильно.

[domandr]

Цитата:

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

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

Может быть в типовой фильтров и не было, но возможности у языка были, возможно с 7.5 (точно не помню):

УстановитьОтбор(<?>,);
Синтаксис:
УстановитьОтбор(<ИмяОтбора>,<ЗначениеОтбора>)
Назначение:
Установить отбор списка справочника.
Параметры:
<ИмяОтбора> - строка с именем реквизита справочника (по которому возможен отбор, т.е. взведен флажок ''Отбор по реквизиту'' в свойствах реквизита справочника), по которому установлен отбор. Если это значение пустое, то отбор отключается.
<ЗначениеОтбора> - необязательный параметр. Значение отбора.
Замечание:
Метод доступен только в контексте Модуля формы списка справочника и относится ко всему текущему справочнику.

[domandr]

То есть, здесь такая дилемма:
В 1С не было фильтров в типовых, но было дерево,
В Axapta есть фильтры, но нет деревьев.

И там, и здесь, чтобы достичь желаемого результата - надо дорабатывать.

А все таки дерево - это круто. И идет это не только из 1С, а из многих программ, в том числе не тиражируемых, которые писали грамотные программисты, и знали что, такое списки, кольца, деревья, Би-деревья и прочее. И набирать накладные быстрее все таки в 1С.

[komar]

Набирать накладные быстрее всего в системе с алфавитно-цифровым экранчиком, имея пару "горячих" клавиш. Графический интерфейс на порядодк медленнее. Набирать накладные в Акзапте не медленнее, если у Вас нормально настроенный номенклатурный справочник и Вы умеете пользоваться системой. Готов устроить соревнования.
Дерево красиво смотрится. Но по сути ничем не отличается от фильтров и группировок в "плоской" таблице. А группы, в свою очередь, ничем принципиально не отличаются от грамотно сделанной кодировки справочника.

[domandr]

Цитата:

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

Готов устроить соревнования.

На чьей номенклатуре? Вашей, нашей? И кто будет участвовать? Операторы нашего предприятия знают свою номенклатуру (~100тыс.наименований) как все свои 5 пальцев. И операторы точно сделают быстрее кого-либо.

[domandr]

Цитата:

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

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

А вот в накладную приходится набирать допустим 200 строк наименованиями из разных групп. В Axapta придется все равно сделать несколько лишних движений, чтобы установить фильтры, а в 1С при помощи горячих клавиш легко перемещаться по группам.

[mazzy]

Цитата:

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

В Axapta придется все равно сделать несколько лишних движений, чтобы установить фильтры, а в 1С при помощи горячих клавиш легко перемещаться по группам.

Это как сделать.

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

[domandr]

Цитата:

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

Это как сделать.

В 1С клавиши Ctrl+Вверх и Ctrl+Вниз, операторы работают действительно быстро, так как знают отлично номенклатуру, не используют практически мышь.

[Dzemon]

Цитата:

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

В 1С клавиши Ctrl+Вверх и Ctrl+Вниз, операторы работают действительно быстро, так как знают отлично номенклатуру, не используют практически мышь.

А если еще и со штрих-кодами работать - скорость утраивается!

[Andrew_Lan]

Здравствуйте, уважаемые участники форума! Разрешите высказать кое-какие соображения по обсуждаемому вопросу.

1. Прежде всего, хочу сказать, что я полностью согласен с мыслью MAZZY о том, что "иерархическое представление является удобным только для ОДНОГО пользователя". Запомним эту посылку.

2. По-моему, в дискуссии немного смешиваются такие понятия, как "для чего нужна иерархия" и "почему иерархическое представление является удобным". Ответ на первый вопрос - в статье MAZZY: "чтобы пользователь быстро искал информацию".
Ответ на второй вроде бы тоже очевиден - потому что так можно быстро найти информацию! Но, на мой взгляд, дело немного в другом. Всё дело, по-моему (и не только), в том, что ОДНОЙ МЫШКОЙ работать с иерархическим справочником гораздо сподручнее, чем пользуясь попеременно ТО клавиатурой, ТО мышкой. В этом и кроется то пресловутое удобство. Это психология, и с этим ничего не поделаешь (да и не надо!). НО!!! Это не означает автоматически, что работа при этом реально ускоряется (в секундах, минутах)!

3. Необходимо предложить обьективные критерии ДОПУСТИМОСТИ ПРИМЕНЕНИЯ (именно так категорично) иерархических справочников. Я бы даже более строго подошёл к оценке такой допустимости, чем MAZZY в вопросе "правил размещения элементов в иерархии".
Во-первых, "В каждой группе должно быть небольшое число элементов". По-моему - не более 10-15 (а не 20-40).
Во-вторых, "дерево не должно быть очень глубоким". По-моему - не более 3-4-х уровней.
В-третьих, в таком справочнике НЕ ДОЛЖНО быть элементов, с разным успехом относящихся к разным группам. Простой пример - справочник контрагентов. Я, возможно, выскажу крамольную мысль, но этот справочник МАЛО ПОДХОДИТ на роль иерархического справочника! Ведь один котрагент может выступать и как поставщик, и как покупатель!
Согласно первым двум критериям, максимальное число элементов в справочнике не должно превышать 50000. Согласитесь, это уже очень много.

4. Необходимо подходить к иерархическому справочнику, как к одному из элементов инструмента для ведения бизнеса, т.е. подсчитать затраты на реализацию такого справочника и время (что, в конечном итоге, как известно, тоже деньги), затрачиваемое пользователями на работу с таким справочником. Тут в дискусии предлагали устроить соревнования по быстроте работы со справочником. Но только для чистоты эксперимента в нём должны участвовать не "Операторы нашего предприятия знающие свою номенклатуру (~100тыс.наименований) как все свои 5 пальцев" (domandr), а пользователи, не знакомые, так сказать, "с вопросом".

5. Мысль о том, что "пользователи так привыкли", а тем более придание ей статуса логического обоснования, может привести к очень опасному заблуждению. Иными словами, потакать пользователю, идти у него на поводу - очень плохая идея. Я знаю программистов, которые исповедуют принцип - "что мне скажут, то я и сделаю". Имеется ввиду, попросят меня переписать программу так, чтобы напечатать отчёт "не провдоль, а по-диагонали", я быстенько, не углубляясь в предметную область, запрограммирую такой отчёт с минимальными умственными затратами. Нередко после этого пользователь счастлив и доволен. И вроде как я тоже при деле. На самом деле это путь в никуда. Неисчислимое множество таких программеров в тысячах организаций и
учреждений разной формы собственности (на просторах России, разумеется) вот уже второй десяток лет только и занимаются тем, что бесчисленное множество раз переписывают и исправляют устаревшие и никого уже не удовлетворяющие "программки". По желанию пользователей... (Хотя, справедливости ради надо сказать, что дело здесь не только и не столько в самих пользователях) На самом деле пользователи зачастую и сами не знают, что им реально нужно и что для них удобно. А потом возникает вопрос - а почему у нас выпускается гораздо большее количество специалистов в области ИТ-индустрии и программистов на душу населения у нас больше, чем, например в той же Индии, а уровень развития наших собственных информационных технологий - несоизмеримо ниже?

6. MAZZY: "Как сделать фильтрацию более удобной, чем иерархия. ... Необходимо, чтобы пользователь мог выбрать значение фильтра из списка. ... Желательно, чтобы была возможность использовать выражения и метасимволы в фильтрах. ... Желательно, чтобы была возможность группировать фильтруемые поля в наборы". Вам это ничего не напоминает?! Всё это уже реализовано "один-в-один" в MS Excel! Может, проще передавать список(таблицу) в Excel, и там изгаляться над ним? Но это я так, к слову .

7.Из дискуссии в этом форуме:
Dzemon: "Ээээээээ......... А иерархия это не плоская таблица?"
MAZZY: "нет."
Секунду! Но для того, чтобы список был иерархическим (точнее, смог быть представлен в виде дерева), ДОСТАТОЧНО добавить в таблицу-справочник ПОЛЕ СО ССЫЛКОЙ на идентификатор элемента (записи), являющегося группой (или родителем, если хотите) по отношению к текущему элементу и находящегося в этой же таблице, и, возможно, ПОЛЕ СО ЗНАЧЕНИЕМ уровня иерархии (0 означает самый верхний уровень). Вот это и есть самая, что ни наесть, плоская таблица. Кстати, в 1С иерархические справочники построены именно на таких таблицах (в V7.7, по крайней мере).

8. По-моему, если уж и говорить об иерархических справочниках, то только как о наделённых более полезными и утилитарными свойствами, чем крайне субъективной и никем не оцененной (в РУБ, USD, EUR) способностью быть "удобными". Ну, папример, свойством предоставлять разный уровень доступа для разных пользователей к разным группам. Один пользователь видит из справочника "Сырьё, материалы и оборудование" только группу "Горюче-смазочные материалы", а другой - только "Металлопрокат". Или, например, автоматическое использование разных алгоритмов для групп "Начисления" и "Удержания" при расчёте заработной платы. Список этот может быть ограничен только вашей фантазией!

РЕЗЮМЕ.
- Иерархический справочник должен быть НАСТРАИВАЕМЫЙ. Т.е. для разных пользователей он должен быть свой (см. п.1), и отражать только те данные и значения, с такой группировкой и в такой совокупности, которые позволены данному конкретному пользователю его полномочиями, мерой ответственности и компетентности. Это, кстати, отвечает желанию MAZZY, "чтобы была возможность группировать фильтруемые поля в наборы". Только в случае настраиваемых "деревянных" справочников такие наборы фильтруемых полей будут представлять из себя наборы группировок разной глубины вложенности.
- Должны неукоснительно соблюдаться правила ограничений по применению иерархии (см. п.3). НО! Эти правила должны соблюдаться непосредственно самими пользователями или теми, кто настраивает и сопровождает ПО. А программное обеспечение должно предоставлять возможность работать с НЕОГРАНИЧЕННЫМ количеством уровней иерархии и набором группировок.
- Необходимо отделить структуру данных, хранящихся в базе данных, от визуального представления иерархического справочника. Пусть данные в базе лежат так, как им и положено по правилам нормализации и хранения в РСУБД, а справочник отображается так, как "удобно пользователю"!

Ну вот, вроде и всё. Приношу извинения за свою многословность и некоторую сумбурность мыслей, но хотелось быть немного полезным.

Удачи

З.Ы. Я 17 лет работаю в сфере ИТ-индустрии, своими собственными глазами видел, как всё начиналось (начиная с XT и AT286), своими собственными руками всё "пощупал", и, надеюсь, имею какое-то минимальное представление о предмете обсуждения.

[mazzy]

Опубликовал вторую часть.
Иерархический справочник и Axapta. Часть 2: Постановка задачи
http://axapta.mazzy.ru/articles/tree2/


Приношу свои извинения. К сожалению, в связи с загрузкой, никак не доберусь до того, чтобы подготовить и выложить последовательность проектов.

Обязательно сделаю.

[mazzy]

Цитата:

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

8. По-моему, если уж и говорить об иерархических справочниках, то только как о наделённых более полезными и утилитарными свойствами, чем крайне субъективной и никем не оцененной (в РУБ, USD, EUR) способностью быть "удобными". Ну, папример, свойством предоставлять разный уровень доступа для разных пользователей к разным группам. Один пользователь видит из справочника "Сырьё, материалы и оборудование" только группу "Горюче-смазочные материалы", а другой - только "Металлопрокат". Или, например, автоматическое использование разных алгоритмов для групп "Начисления" и "Удержания" при расчёте заработной платы. Список этот может быть ограничен только вашей фантазией!

Спасибо, Andrew_Lan.

Позволю себе не согласится только с одним пунктом.
Это rls - record level security.
Что такое RLS?
http://axapta.mazzy.ru/hints/rls_setup/
иерархия для ограничения досутпа на уровне записей тоже не нужна

[mazzy]

Цитата:

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

- Необходимо отделить структуру данных, хранящихся в базе данных, от визуального представления иерархического справочника. Пусть данные в базе лежат так, как им и положено по правилам нормализации и хранения в РСУБД, а справочник отображается так, как "удобно пользователю"!

Да! Тысячу раз "да"!

[domandr]

Цитата:

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

...максимальное число элементов в справочнике не должно превышать 50000. Согласитесь, это уже очень много.

Видел справочник из 2-х строчек
- свинина высшей категории;
- свинина 1-й категории.

Да 50 000 элементов много. А почему не должно? Очень даже может быть. Например, часы, сколько фабрик, коллекций, артикулов, каждый сезон появляются новые, и вы думаете их можно строго ограничить цифрой в 50000. А вот если взять ювелирную продукцию, так там каждое изделие - отдельная строка в накладной (со своим спец.номером). Тут, то как?

[mazzy]

Цитата:

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

А вот если взять ювелирную продукцию, так там каждое изделие - отдельная строка в накладной (со своим спец.номером). Тут, то как?

Это вовсе не значит, что для каждой строки надо заводить строчку в номенклатурах. Достаточно серийных номеров. Не так ли?