iscrafm mazzyЖаль, а это и есть попытка представить пользователю быстрый доступ к нескольким миллионам элементов...
Причем реализация доступна всем участникам обсуждения. Если не обсуждать каталог Яндекса (или другого поисковика), то придется рассуждать на пальцах... :(

mazzy, просто у этих большинства участников подобные вещи и не в одном варианте давно реализованы, имхо. Не знаю как для других участников обсуждения столь животрепещущей темы, но для меня этот вопрос лет 10 точно не стоит. Я Вам и сказал в самом начале - пытаетесь толочь воду в ступе.
Еще раз, iscrafm.
Если для вас неинтересная тема - не участвуйте.
Наличие или отсутствие подобной фичи не повод пообсуждать саму задачу.

Продолжим с теми кому интересно?

Об иерархии я начал задумываться очень давно.
Еще когда сам начал писать на ФоксПро, затем когда появилась иерархия в 1С:Бухгалтерии 6.0...

Итак, iscrafm продолжает настаивать на индивидуальных каталогах.
Для новых элементов предлагает использовать "спец.группу" Новые.
Ок. рассмотрим этот вариант.

Как бы это ни казалось очевидным, но хотелось бы напомнить о том, что мы находимся в разделе ERP и учетные системы. Большинство таких систем являются многопользовательскими. Многопользовательские системы характеризуются одним очень важным моментом - информацию вводят и используют РАЗНЫЕ люди.

Еще раз - справочник должен быть удобным для РАЗНЫХ людей.
Справочник должен быть удобным как для ввода, так и для поиска.
Справочник должен быть удобным как для давно работающих пользователей, так и для новых.

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

Теперь вернемся к предложению iscrafm.
Предположим, система работает давно, содержит несколько тысяч элементов.
Многие сотрудники уже рассовали элементы по индивидуальным группам.
Теперь представьте, что приходит новый сотрудник (такое случается, не так ли?)

Что получит этот новый сотрудник, если в системе есть индивидуальные папки?
Он получит единственную группу "Новые", в котором будет линейный список всех элементов. (!!!)

Предположим система поддерживает некие предопределенные группы плюс индивидуальные группы.
В этом случае новый сотрудник получит набор предопределенных группировок плюс одну супер группу "Новые". (плюс геморройную задачу рассовать элементы по своим группам)

Таким образом, суперфункциональность "индивидуальные группы" по сути своей вырождается в две задачи - создать единый и стандартный набор группировок ПЛЮС поиск в большом линейном списке под названием "Новые". :)

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

Кидман iscrafm Я Вам и сказал в самом начале - пытаетесь толочь воду в ступе.
Может я не прав, но я полагаю, что Mazzy хочет опровергнуть попсовое заблуждение, что система без многоуровневого справочника ущербна по сравнению с системой обладающей таковым. А то, что реализаций деревьев полно (и удачных в том числе), с этим никто не спорит.
Спасибо. Можно и так сказать.

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

Итак, хотелось бы вернуться к исходным определениям.
Зачем нужна многоуровневость?
Для:
1. быстрого поиска
2. группировок в отчетах
все. По-моему других пунктов нет.

Так ли это?
Есть ли другие причины для введения многоуровневости?

Что скажете насчет отчетов?
В отчетах группы используются для агрегирования данных из своих элементов.
Например, в скриншоте iscrafm агрегируются даты (как в MS Project)
Например, в 1С группы используются для суммирования данных.
И т.п.

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

iscrafmВы когда файлы по своему усмотрению раскидываете...
ВЫ?
Я для себя любимого раскидываю.

Но еще раз напомню, мы говорим о многопользовательских системах.

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

Это означает, что поисковые и отчётные группы похожи только внешне.
Еще раз напомню,
Зачем нужна многоуровневость?
Для:
1. быстрого поиска
2. группировок в отчетах
все. По-моему других пунктов нет.

iscrafm mazzy
Но еще раз напомню, мы говорим о многопользовательских системах.
А я про какие собственно? :)
А вы про однопользовательские.

Цитирую: "Если захочет (ед.число) ... будет пользоваться(ед.число)... Вы (обращение, ед.число)... Я (ед.число)[/quot]

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

Попробуйте и сразу почувствуете разницу.

iscrafm mazzy
1. быстрого поиска
2. группировок в отчетах
все. По-моему других пунктов нет.
Есть еще самый главный, 0-й пункт: информация по природе иерархическая. п1. решается разными способами, один из них каталогизация информации. И еще куча других, в том числе поисковые алгоритмы, фильтрация, упоминавшиеся здесь глоссарии и т.п. п2 - тоже применяется.
Приведете пример иерархической по природе информации из нашей области - ERP и учетные системы?

Затем приведите пожалуйста приемлемую для многопользовательской системы иерархию для этой информации. :)

iscrafmп1. решается разными способами, один из них каталогизация информации. И еще куча других, в том числе поисковые алгоритмы, фильтрация, упоминавшиеся здесь глоссарии
Отлично!
К п.2 мы еще вернемся.

Хотелось бы напомнить иходный тезис: "думал, что одноуровневые группы остались где-то в начале 90-х в DOS-овских системах"

Итак, должна современная система в ОБЯЗАТЕЛЬНОМ порядке использовать многоуровневые справочники, если существует куча других алгоритмов?

Если должна, то каталог яндекса является либо:
а) не современной системой
б) не многоуровневым справочником
в) не решает задачу быстрого поиска

iscrafm mazzyЕсли должна, то каталог яндекса является либо:
а) не современной системой
б) не многоуровневым справочником
в) не решает задачу быстрого поиска
Для начала нужно выяснить: кто Вам сказал, что каталог Яндекса не является многоуровневым? Потом можно продолжить.

p.s. Здесь уже говорилось о том, что способ представления иерархических данных в виде TreeView не является единственным.
Нужно быть крайне невнимательным, чтобы не заметить слово ЛИБО.
Повторяю:
...то каталог яндекса является либо:
а) не современной системой
б) не многоуровневым справочником
в) не решает задачу быстрого поиска

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

iscrafm mazzyПриведете пример иерархической по природе информации из нашей области - ERP и учетные системы?

Нужно быть крайне невнимательным, чтобы не заметить хотя бы 2 картинки в этом топике.
Картинки я заметил.

Правильно ли я понял, что вы полагаете, что на картинках отображена "иерархическая по природе информация"

iscrafm iscrafm
Нужно быть крайне невнимательным, чтобы не заметить хотя бы 2 картинки в этом топике.
Ну про BOM я вообще промолчу. Весьма странно, что Вы сами не знаете таких примеров. Вы с производством сталкивались на практике?
iscrafm, правильно ли я понимаю, что вы считаете что BOM является примером иерархической ПО СВОЕЙ ПРИРОДЕ информации?

Вы уверены, что именно BOM является ИЕРАРХИЧЕСКОЙ структурой, а не является графом ?
Или вы случай, когда один узел/материал входит в несколько BOM не рассматриваете?