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

[Alks]

Цитата:

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

Гхм... Т.е. вы изначально даже предположить не могли что дополнительный флэш-модуль памяти может лежать в разделе "модули памяти"?
Я тут промолчу, просто хочу сказать если я ищу по классификатору и дохожу до дна не найдя нужного - я просто возвращаюсь на уровень выше и продолжаю искать ниже...

Цитата:

Простой пример, когда дерево летит к чертовой бабушке: как правильно строить дерево? По вендору?  (Я например, сразу хочу отфильтровать по вендору IBM) Или по группе? Или по типу? Мне, как потребителю, неудобно пользоваться чьей иерархией.

Это мы уже тут проходили - то о чём вы говорите это то что мы ранее условились называть ненормализованным деревом. Правильно строить дерево надо по ассортименту и только по нему. Вендоры и прочие характеристики товаров должны отсекаться фильтрами. Фильтр же по ассортименту тем уникален, что даже если он внешне будет выглядеть как просто серия страничек с сужающимся критерием, в СУБД его рационально хранить в виде дерева.

Цитата:

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

Фильтры то в этом ему точно не помогут. А вот я по себе наоборот заметил, что видя оглавление ассортимента верхнего уровня ну например

мониторы
процессоры
мат. платы
дисководы
цифровы фотоаппараты

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

Цитата:

P.S. Коллеги. Иерархию имеет смысл использовать там, где что-то суммируется. В номенкатурном справочнике ничего не суммируется!

И там тоже. А так же там, где свойство (одно) объекта, образует "нормализованное" дерево. Как ассортимент например.

[Тимур_imported]

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

На счет новинок. Это делается по принципу появления данной позиции в справочнике (поле дата). Не хуже меня знаете ответ.

А многие так и просматривает новинки. Вот есть у меня ноутбук IBM. Так вот я сразу предпочитаю "чужую" продукцию отсечь по коду вендора.
Мне так удобно, да и думаю большинству так удобно.
Ведь люди ориентируются на бренды прежде всего.
Кто-то на все от Microsoft, а кто-то молится на 1с (включая технологические решения)
Разве не так?

[mazzy]

Цитата:

Сообщение от Maxim Gorbunov

Цитата:

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

Цитата:

Сообщение от Marshak IX

Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?

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

Еще раз выскажу свое мнение: "правильной" реализации дерева в Axapta нет. Варианты реализации дерева на основе реляционной СУБД описаны в статье на SQL.RU (ссылка уже дважды давалась выше по теме). В том числе там есть вариант, который mazzy описывает и в своей статье. Каждый из вариантов, по моему убеждению, имеет право на существование, а выбор конкретной реализации в каждом конкретном случае диктуется условиями задачи.

Полностью согласен.

Придется развернуть ответ: хотелось привети реализацию отличную от связки (ParentId - Id) и от загрузки всей иерархии в treeView (как это делается в форме установки прав доступа).

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

[MArshak IX]

Цитата:

Сообщение от =A=L=X=

Так, по мелочам поправлю MarshakIX:

Цитата:

Цепочка ввода документов (заказ, счет, накладная, счет-фактура, приходный кассовый ордер, возвратная накладная и т.д.)
...
Последовательность выполнения процедур бизнесс-процесса (как меня задолбала в нешей фирме выписка командировочных... кто бы знал!..)

В данном случае идет речь скорее о древовидном представлении информации, а не древовидном хранении.

Можно уточнить, что имеется ввиду?
Ибо во всех перечисленных мною вариантах существует реквизиты
ID и ParentID, либо их явные аналоги.

[MArshak IX]

Цитата:

Сообщение от =A=L=X=

Цитата:

А вот если попробовать просуммировать по группам номенклатурных поциций

По себе знаю - привычку суммировать по группам номенклатурных позиций имеют программисты и пользователи 1С. У нас на предприятии таким образом обычно оцениваются целиком торговые отделы (которых сравнительно немного и реализованы они могут быть простым для аксапты способом - через одну из финансовых аналитик). Вот с итогами по подгруппами уже сложнее - с одной стороны менеджеру интересно бывает поанализировать свои товары целиком по подгруппам, но если задуматься тут возможны варианты, как ему добится желаемого используя совсем другую информацию.

Вот в том то и дело, что "нормализованное" дерево позволяет решить задачу суммирования ресурса по всем уровням иерархии дерева. Именно об этом и говорю, что это одно из назначений иерархического списка.

[MArshak IX]

Цитата:

Сообщение от =A=L=X=

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

Кстати, хотел бы напомнить, что я абсолютно был согласен, со всем тем, что было произнесено в данном топике. Особенно про "нормализацию" дерева!!! Это именно то, что мне не хватало!

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


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

[MArshak IX]

Цитата:

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

P.S. Коллеги. Иерархию имеет смысл использовать там, где что-то суммируется. В номенкатурном справочнике ничего не суммируется! Даже если будет в таблице товаров хранится информация о материнском узле, то в другие таблицы (где собственно используется номенклатура), она не будет попадать, а если попадает - то это на мой взгляд, увеличение базы данных - "бездумное и беспощадное".

Либо я чего-то не догоняю, либо что-то не так...

Почему нельзя суммировать по номенклатурным группам:

• Выручку
• Себестоимость ТМЦ
• Налоги
• Затраты
• Маржинальную прибыль
• и т.д.

???

[MArshak IX]

Цитата:

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

Цитата:

Сообщение от Marshak IX

Кстати, почему в САПе вводится отдельный справочник "Номенклатурные группы" именно для эмуляции дерева справочника Номенклатуры, но этот справочник не позволяет дальнейшей детализации.

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

Ну не могу сказать отчего в SAP R/3 это сделано, потому что в первый раз слышу, что есть такая визуализация как иерархия в справочнике "Материалы".
:P

Я вот в итоге, напротив, предлагают говорить о прикладных к бизнесу вещах, и забыть про "замечательные технологии".

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

[MArshak IX]

Кстати, просвятите, пожалуйста, а что такое BOM в Аксапте?
Что это за зверь и почему этому зверю требуется иерархия?

[mazzy]

Цитата:

Сообщение от Marshak IX

Кстати, просвятите, пожалуйста, а что такое BOM в Аксапте?
Что это за зверь и почему этому зверю требуется иерархия?

BOM = спецификация в ИТРП.

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

[Alks]

Цитата:

А как же быть с модулем памяти для ноутбука?
Почему я как потребитель должен его искать среди модулей памяти, если на верхнем уровне рядом с комплектующими стоят ноутбуки, компьютеры, фотоаппараты?

Постойте ка, постойте ка...

Цитата:

"рядом с комплектующими стоят ноутбуки, компьютеры, фотоаппараты"

модуль памяти -это ноутбук?
модуль памяти - это компьютер?
модуль памяти - это фотоаппарат?
модуль памяти -это модуль памяти? ***

правильный вопрос помечен тремя звездочками.
Блин... может я какой то продвинуты пользователь что понимаю такие простые вещи? Или погружение ООП сказывается.... Не знаю...
Знаю только одно, если конечный пользователь не понимает таких простых вещей, ему и "плоские" фильтры не помогут, т.к. он будет искать в них "ОЗУ", или "оперативку", а когда не найдет, то недовольно фыркнув уйдет с сайта.

Цитата:

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

А вы понимаете что эта идея не только выигрывает, но и проигрывает id/parent подходу?
Нормализованное дерево не подчиняется тем рамкам в которые вы его пытаетесь загнать - подход многие-ко-многим работает отлично, но подход id/parentId -это следующее поколение иерархичности данных и тот же BOM вы никак не загоните в рамки "нужных количеств классификаций". Так же как и каталоги на вашем жестком диске. Так же как и ассортиментный классификатор на 50000 товаров в теоретическом веб-магазине.

Цитата:

А многие так и просматривает новинки. Вот есть у меня ноутбук IBM. Так вот я сразу предпочитаю "чужую" продукцию отсечь по коду вендора.

Я не против фильтров, отнюдь. Но еще раз замечаю- попоробуйте реализовать фильтр по поставщику в среде с 50000 товаров, где каждой группе и подгруппе товаров актуальны только небольшие и разные наборы поставщиков... Тут нужен настолько smart-подход, что деревья и плоскости перемешаются в нём изрядно.

Цитата:

Мне удобно, да и думаю большинству так удобно.
Ведь люди ориентируются на бренды прежде всего.
Кто-то на все от Microsoft, а кто-то молится на 1с (включая технологические решения)
Разве не так?

Т.е. по вашему большинству людей (включая вас) удобно ориентироваться на бренды? Интересное заявление, т.к. я например на бренд ориентируюсь В ПОСЛЕДНЮЮ ОЧЕРЕДЬ, именно тогда когда выберу тот ассортимент товаров и ту нишу котрую они занимают, я уже присматриваюсь к фирмам-производителям и ценам, решая кто из них достойней.

Вы же, Тимур, буквально только что сказали что для вас главное - бренд, а тот товар (ассортимент) который вы покупаете у бренда интересует вас уже во вторую очередь. Т.е. вышли однажны на улицу и решили купить что нибудь от Sony. И в раздумиях тяжелых решаете что же это будет - телевизор, сотовый телефон или мп3-плеер.
Это бред Тимур. Бред, бред и еще раз - бред.

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

[MArshak IX]

И на сегодня последнее сообщение!
Сразу извиняюсь, может это ОФФ-ТОПИК, но думаю, что вопрос является логическим продолжением последовательности: линейный список, иерархический...

Никто не сталкивался с опубликованным алгоритмом визуализации произвольного графа?

Заранее спасибо!

[Alks]

Marshak IX

Цитата:

Можно уточнить, что имеется ввиду?
Ибо во всех перечисленных мною вариантах существует реквизиты
ID и ParentID, либо их явные аналоги.

Нет не во всех - те которые я "окритиковал" в идеологии хранения в СУРБД легче хранить как отношения один-ко-многим, и лишь для каких то своих целей вырисовывать на экране комптютера в виде TreeView, т.к. людьми часто древовидное представление данных легче воспринимается. Пример - мониторинг проводок в аксапте (забыл как точно форма называется - там именно в виде дерева отображаются проводки, хотя в базе они хранятся в плоском виде).

Цитата:

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

Согласен. Если дерево "нормализовано", то отдельными его ветвями всегда имеет смысл оперировать так же как и отдельными листьями.

Marshak IX

Цитата:

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

А я так и считаю - номенклатурный ассортимент - очень специфическая вещь имеющая право на жизнь по многим причинам.

MAZZY

Цитата:

Придется развернуть ответ: хотелось привети реализацию отличную от связки (ParentId - Id) и от загрузки всей иерархии в treeView (как это делается в форме установки прав доступа).

Это обычные отношения один-ко-многим и, может быть многие-ко-многим. Разве есть смысл их приводить в пример там где ими пропитана вся система?

[mazzy]

Цитата:

Сообщение от Marshak IX

Никто не сталкивался с опубликованным алгоритмом визуализации произвольного графа?

графа - нет.
дерева - да. Но платно
http://www.inxight.com/products/vizserver/features.php

здесь краткий тур по этой приблуде
http://www.inxight.com/products/sdks/st/tour_st_1.html

а вот здесь она работала
http://www.lexisnexis.com/startree/interactiveview.asp

[mazzy]

Цитата:

Сообщение от =A=L=X=

Это обычные отношения один-ко-многим и, может быть многие-ко-многим. Разве есть смысл их приводить в пример там где ими пропитана вся система?

Имеет.

До этой статьи каждое второе письмо было с вопросом о дереве.
Я писал пространные письма с ответами и разъяснениями.
Сейчас писать каждый раз больше не нужно

Осталось только закончить пример.
Тогда можно будет не разъяснять каждый раз "а как надо?"

[Тимур_imported]

Цитата:

Сообщение от Marshak IX

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

Хм. О каких деревьях идет речь, если их не видно? Миражи разработчика не иначе.
С таким же успехом можно назвать иерархиеческим деревом любые 2 связанные между собой справочника.

Опять мы от прикладных вещей уходим в сторону кишок системы. Давайте уже будем к нуждам пользователей ближе.

[Тимур_imported]

Цитата:

Сообщение от Marshak IX

Цитата:

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

P.S. Коллеги. Иерархию имеет смысл использовать там, где что-то суммируется. В номенкатурном справочнике ничего не суммируется! Даже если будет в таблице товаров хранится информация о материнском узле, то в другие таблицы (где собственно используется номенклатура), она не будет попадать, а если попадает - то это на мой взгляд, увеличение базы данных - "бездумное и беспощадное".

Либо я чего-то не догоняю, либо что-то не так...

Почему нельзя суммировать по номенклатурным группам:

• Выручку
  
  
• Себестоимость ТМЦ
  
  
• Налоги
  
  
• Затраты
  
  
• Маржинальную прибыль
  
  
• и т.д.

???

Потому что иначе придется складывать учетные данные с учетом номенклатурной иерархии. А это неправильно! Учетные данные должны собираться на самом нижнем детализированном уровне, а не на узлах.
Пример:
Группа - Зерно.
Подгруппа - Пшеница
Вид номенклатурной позиции - Пшеница высшего сорта твердая.
Вид номенклатурной позиции - Пшеница высшего сорта мягкая.
В транзакциях (например, в строчках по продажам) должно быть значение Пшеница высшего сорта твердая, а не Пшеница.
Классификаторы как раз так и предполагают организовывать работу. В ряде случаев визуально данную классификацию можно отобразить в виде дерева. Но я уже выше приводил примеры, когда это делать нецелесообразно: компьютерный бизнес один из примеров.

Кстати, ты попробуй просуммируй выручку по номенклатурным группам в SAP, затраты. И спроси как это делается. А делается это за счет дублирования связей: в аналитических разрезах как раз и выстраиваются деревья, в той последовательности, которая необходима для конкретного случая, и строится отчет.

[Тимур_imported]

Цитата:

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

Цитата:

Сообщение от Marshak IX

Кстати, просвятите, пожалуйста, а что такое BOM в Аксапте?
Что это за зверь и почему этому зверю требуется иерархия?

BOM = спецификация в ИТРП.

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

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

Спецификация просто не может быть плоской, потому что смысл ее - это сборочное производство! Узел - термин из этой оперы.

[mazzy]

Цитата:

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

Спецификация просто не может быть плоской, потому что смысл ее - это сборочное производство! Узел - термин из этой оперы.

"Плоской"?!
Ты из какой области термин привел?

Здесь рассматривается графы/деревья. Термины из области графов/деревьев.
Граф бывает плоским. Но спецификация не обязательно должна быть плоским графом. Ей достаточно быть нециклическим графом.
Термины из теории графов.

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

[mazzy]

Цитата:

Сообщение от Marshak IX

Никто не сталкивался с опубликованным алгоритмом визуализации произвольного графа?

Ой! Гляди какую штуку я нашел
http://www.touchgraph.com/TGGoogleBrowser.html
она требует загрузки java-апплета.
но оно стоит того.
Нажимать на кнопку Graph It!

Какие клоуны!
http://www.touchgraph.com/index.html
Нажимать на Dynamic Graph Layout
(Ой, держите меня семеро! хочу запустить такую штучку по перекрестным ссылкам!)


и еще забавная штучка
http://gskinner.com/site1/

Marshak_IX, вот оно!
http://java.sun.com/applets/jdk/1.2/demo/a...t/example4.html

а здесь free алгоритм для perl
http://www.compendiumdev.co.uk/perltools/examples.php