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

[Тимур_imported]

Нет, господа, не убедительно!

Давайте четко разграничим пользователей: клиент, менеджер продаж, комм.директор, оператор офиса продаж.

Итак. Клиент не будет бродить по иерархии. Хотя бы потому что он не знает к чему относится память для ноутбука. Ну вот ламер я.
Тем более, что разные магазины/покупатели по-разному классифицируют продукт.
Вместо того, чтобы сразу отсеять лишние позиции, я вынужден искать по веткам дерева. Информация о новинках мне и так предложена на главной странице магазина. Люди, которые думают, чтобы прикупить, делают это вне магазина. (это до выбора типа товара). Ну нет смысла бродить по деревьям. Есть фильтры "ценовая категория".

Сколько значений имеет каждый классификатор? Не думаю, что гигантское количество. Ассортимент возникает за счет комбинаций классификаций.
Достаточно поглядеть, например, на группы/подгруппы магазина mvideo.ru

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

Поймите, покупатель вовсе не собирается изучать всю номенклатуру магазина. Это ОЧЕНЬ РАЗДРАЖАЕТ любого покупателя. А это приходится делать, если предлагается деревья. Вспомните ваши ощущения, когда в супермаркете, в который привыкли ходить за покупками, вдруг изменилось месторасположение товаров?
Вобщем ок. Допустим каналы связи у всех отличные, по деревьям бегать не проблема для покупателя.
Теперь про менеджера продаж. Вот эти ребята, как ты четко подметил, обязаны знать свою номенклатуру. Поэтому им даже фильтра не нужна. Они по коду порядковому должны помнить товар, или на крайний случай по коду вендора или краткому имени.
Заметьте, покупатель - это не пользователь ERP-системы, менеджер = ползователь. Аналогично оператор: он работает по бумажке, в которой стоит код товара, и кладовщик (они смотрят на код вендора, на складские места - маркировку упаковок). Комм.директор, который ответственнен за прайс-лист компании нужен этот прайс-лист в виде отчета. Так кому из пользователей ERP-системы нужен иерархический справочник???

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

P.S. Теперь только без обид. Текст основан на моем практическом опыте работы.
Как складывать номенклатурные единицы в справочник, какой информацией наполнять его - от этого зависит на сколько им удобно пользоваться и даже какова степень интеграции данных в системе. Товарищи-консультанты по логистике - это часто бывшие разработчики. Так вот иногда им кажется, что логистика - это очень просто и не требует спец.знаний предметной области. Поэтому то и плохо готовят номенклатурный справочник. Вместо правильной классификации идут на поводу у пользователей и своего желания "попрограммить". Ну как же, надо же и свою лепту внести в код большой системы.
Я бы сказал, что использование иерархического справочника номенклатурных единиц - это скорее психологическая проблема, нежели объективная необходимость. У человека, не испорченного некоторыми российскими системами-конструкторами, таких проблем не возникает.

Вобщем, select - рулез форева!

[mazzy]

mvideo.ru - отличный пример. Спасибо.

[Alks]

Цитата:

Итак. Клиент не будет бродить по иерархии. Хотя бы потому что он не знает к чему относится память для ноутбука. Ну вот ламер я.

Дык такой ламер и филтры будет не в состоянии применить, как вы этого не понимаете? И вообще высказываение спорное, не подкрепленное ничем.

Цитата:

Тем более, что разные магазины/покупатели по-разному классифицируют продукт.

Тем не менее никогда не засунут DVD-плеер в категорию стиральных машин - этого достаточно.

Цитата:

Сколько значений имеет каждый классификатор? Не думаю, что гигантское количество.

Если развернуть наш классификатор на полную глубину получается около 1000 строк. Вот так то.

Цитата:

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

Вооот. Очень наглядный пример двухуровневого дерева, размеры которого позволили очень мелким шрифтом разместить его на одной странице. Хороший подход, однако у нас раздел "бытовая техника" лишь один из 13-ти. Кстати, можно таким же образом вывернуть первые две группы, при выборе которой осуществляется переход на вторую страничку с третьей и четвертой подгруппами, так что всего за два клика можно путешествовать по нашему дереву. Спасибо за наводку на эту идею, в будущем очень может пригодится в веб-магазине. Однако в самом справочнике товаров в Аксапте нет места под такую площадь - классификатор в TreeView ютится на 20% площади формы.

Цитата:

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

Я не против этого. Но дерево есть даже на mvideo.ru, и у него там очень удачное представление.

Цитата:

Поймите, покупатель вовсе не собирается изучать всю номенклатуру магазина. Это ОЧЕНЬ РАЗДРАЖАЕТ любого покупателя.

ИМЕННО ПОЭТОМУ ЕМУ НУЖЕН ДРЕВОВИДНЫЙ КЛАССИФИКАТОР, как вы не понимаете в самом деле. Именно такой классификатор позволяет с минимальными усилиями справится с изучением только интересующей номенклатуры.

Цитата:

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

С этим я согласен. Но кроме менеджеров в магазине есть например продавцы, которые могут увольнятся и наниматься на работу - для них изучить номенклатуру без хорошего классификатора - целая проблема. За сутки статистика использования фильтров на форме InventTable составила у нас:
Создано фильтров по поставщику: 1
По наименованию: 24
По ItemId: 338
По классификатору: 510

Цитата:

Так кому из пользователей ERP-системы нужен иерархический справочник???

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

Цитата:

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

Тогда вы столкнётесь со всеми теми проблемами, в которых пытаетесь обвинить древовидный классификатор - помещение товара в неправильный фильтр и т.п.

Цитата:

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

Ну чтож... Тогда у нас магазин психопатов.

[mazzy]

Цитата:

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

Я не против этого. Но дерево есть даже на mvideo.ru, и у него там очень удачное представление.

Цитата:

Поймите, покупатель вовсе не собирается изучать всю номенклатуру магазина. Это ОЧЕНЬ РАЗДРАЖАЕТ любого покупателя.

ИМЕННО ПОЭТОМУ ЕМУ НУЖЕН ДРЕВОВИДНЫЙ КЛАССИФИКАТОР, как вы не понимаете в самом деле. Именно такой классификатор позволяет с минимальными усилиями справится с изучением только интересующей номенклатуры.

А где там дерево? Можно ссылку или скриншот?

Насчет древовидного представления...
Похоже, это дело привычки.

[Alks]

Цитата:

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

А где там дерево? Можно ссылку или скриншот?

Насчет древовидного представления...
Похоже, это дело привычки.

Тьфу, запутался я уже в терминологии.
Корректнее сказать не дерево, а иерархический классификатор ном-ры.
Мы видим что у них иерархическое представление классификатора н-ры, я нигде не говорил что оно обязано быть деревом. Мы на самом деле никогда не узнаем как храниятся данные в базе mvideo.ru - в дереве, двух связанных таблицах, или в намертво зашито в дизайн страницы без всякого использования СУБД... В последних постах я наоборот напирал на то что Тимур похоже смешивает вопросы представления данных и хранения данных. Я ратую только за то что деревянное хранение данных может имеет смысл в номенклатурном каталоге - а уж отображать его по идее надо как можно более удобным и рациональным способом.
У нас в классификаторе н-ры это рационально сделать только в TreeView по причинам которые я уже сказал.
Тем не менее им пользуются и если его св-во visible на день поставить в false, то раздадутся такие вопли возмущения, что ох и ах.

[mazzy]

спасибо.

[Alks]

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

[mazzy]

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

[mazzy]

производители могут входить в несколько групп.
В том то и дело, что это НЕ дерево.

Обратите внимание на пример реализации деловых отношений в Аксапте с фильтрами. То, что сделано в mvideo - это обычные фильтры.

[Alks]

У них 3-уровневый классификатор из 3-х связанных таблиц.
Первая называется в CGI-интерфейсе lvl, вторая - class, третья - group.
То что группа может находится в другой свидетельствует о подходе многие-ко-многим для связи между группами и, наверное, товаром. Тоже вариант.
Плюс, начиная с третьего уровня, появляется фильтр по поставщику, что несомненно удобно.
Факт остаётся фактом - иерархия классификатора номенклатуры налицо. Поэтому какие тут могут быть аргументы против то, не понимаю?
У нас дерево из 1000 веток - и ничего, привели его в порядок, товар находится только там, где должен быть - только в одном отделе и только на одной полке в этом отделе, зачем всё усложнять?

P.S.
Кстати, в последнюю, третью группу там нередко попадают качества товара, мелочь, а приятно.

[Alks]

Цитата:

То, что сделано в mvideo - это обычные фильтры.

Ну прежде всего, это иерархический классификатор.
Реализация в виде дерева или многие-ко-многим - это техническая деталь.
Что будет делать mvideo, когда число товаров увеличится в 10/20 раз, и ассортимент пополнится раза в два-три?
Перепахивать все свои базы и дизайн сайта?
Это их выбор, они его сделали, я ничего против не имею.

[Alks]

Цитата:

Обратите внимание на пример реализации деловых отношений в Аксапте с фильтрами.

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

[mazzy]

Цитата:

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

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

Не. Это говорит о том, что у товара указывается не Parent, а все ключи к другим таблицам.

И вы очень хорошо сказали "начиная с третьего уровня, появляется".
Не хранится, а "появляется".
Хранение и визуализация - их не надо путать.
Поскольку... фильтр по поставщику доступен с любого уровня

[Alks]

Цитата:

Не. Это говорит о том, что у товара указывается не Parent, а все ключи к другим таблицам.

Как это достигнуть не используя подход многие-ко-многим??

Цитата:

Поскольку... фильтр по поставщику доступен с любого уровня

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

[mazzy]

Извините.

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

Хранение в виде ParentId/Id - вовсе не единственное решение для работы с иерархиями. Мало того, не самое оптимальное.

А вот отображать пользователю можно по-разному...

[Alks]

Цитата:

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

Цитата:

Хранение в виде ParentId/Id - вовсе не единственное решение для работы с иерархиями. Мало того, не самое оптимальное.

Во первых - я этого и не утверждал никогда, во вторых я считаю что для внутриклассовых иерархий id/parentId предпочтительнее, и потому в третьих - будет время, напишу сравнительные тесты скорости построения в treeView деревьев из различных подходов - плоских таблиц образующих иерархию, id/parentId в классическом рекурсивном исполнении и id/parentId по последней предложенной мной схеме. Там проверим насчёт оптимальности воочию.

[Тимур_imported]

Цитата:

Дык такой ламер и филтры будет не в состоянии применить, как вы этого не понимаете? И вообще высказываение спорное, не подкрепленное ничем.

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

Цитата:

Если развернуть наш классификатор на полную глубину получается около 1000 строк. Вот так то.

О как! Вот Алексей то удивится!

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

Цитата:

Тогда вы столкнётесь со всеми теми проблемами, в которых пытаетесь обвинить древовидный классификатор - помещение товара в неправильный фильтр и т.п.

Неправильное значение кода классификатора - это проблема любого справочника. Не решается технически. Решается с помощью человека.

Цитата:

Ну чтож... Тогда у нас магазин психопатов.

Управленческая культура - вещь заразная. Оболванивают под одну гребенку. Главное чтоб гребенка правильная была.

[Alks]

Цитата:

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

Тимур, на mvideo.ru 3-х уровневая классификация товара. Как он был реализован - технический вопрос - пользователь его всё равно видит в строгой иерархии, точно так же как это было бы и при деревянном подходе.
Иерархии дерева тоже можно подгружать только по мере захождении в узел - 1С так и делает.
Ей богу, я вас не понимаю.

[Тимур_imported]

Цитата:

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

Цитата:

То, что сделано в mvideo - это обычные фильтры.

Ну прежде всего, это иерархический классификатор.
Реализация в виде дерева или многие-ко-многим - это техническая деталь.
Что будет делать mvideo, когда число товаров увеличится в 10/20 раз, и ассортимент пополнится раза в два-три?
Перепахивать все свои базы и дизайн сайта?
Это их выбор, они его сделали, я ничего против не имею.

Им нет смысла увеличивать ассортимент.
Опять абстрактные предположения.
Не надо делать суперуниверсальные бизнес-приложения.
Возможности системы должны исходить из практики и теории управления.
А не из технических возможностей средств разработки и платформы.

[mazzy]

Цитата:

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

...будет время, напишу сравнительные тесты скорости построения в treeView деревьев из различных подходов - плоских таблиц образующих иерархию, id/parentId в классическом рекурсивном исполнении и id/parentId по последней предложенной мной схеме. Там проверим насчёт оптимальности воочию.

Отлично.
С удовольствием опубликую на сайте