Вот наконец то нашел место где эта тема обсуждается всерьез.
Не буду комментировать комментировать посты, сразу перейду к обсуждению статьи, которая тут является главным звеном. Много времени нет поэтому обсуждать буду "порциями".
Для начала несколько тезисов:
1. Господство реляционных СУБД (СУРБД) в наше время для разработки деловых приложений бесспорно, так же как то, что Аксапта построена на СУРБД.
2. Так же бесспорно что СУРБД не является идеальным решением в технологиях хранения, обработки и анализа больших объемов информации, но забудем про это пока.
3. Из литературных источников о принципах СУРБД и реаляционной алгебры мы знаем что есть ряд задач, которые СУРБД не могут решать эффективно, в ряд этих задач попадает то что мы тут называем "древовидностью". Поэтому реализация древовидности в СУРБД бесспорно является редко когда практичной задачей - с этим я не спорю. Но давайте посмотрим ниже.
(Теперь собственно комментирование статей уважаемого Mazzy
Цитата:
...В свое время были развиты иерархические СУБД. Однако с появлением реляционных баз данных, иерархические СУБД были незаслуженно забыты...
...На просторах СНГ массовое распространение иерархических справочников в учетных системах и в ERP-системах началось с 1С...
Просто замечаение: Самое интересное, что несмотря на то что 1С работает с СУРБД, если внимательно приглядется к её метамодели данных очевидно становится что... модель справочников 1С представляет собой модель иерархической СУБД!
Даже принципы построения запросов и навигации по этим справочникам аналогичны, если не ошибаюсь, моделям предложенным для навигации в иерархических СУБД. Кроме того у меня создаётся ощущение что концепция регистров в 1С подозрительно похожа на OLAP-кубы.
Т.о. 1С являет собой продукт, который использует СУРБД немного не так как предполагается для них.
Цитата:
Предполагается, что иерархия нужна для того, чтобы пользователь быстро искал информацию.
Имхо, это и есть корень всех разногласий, ибо если принять это положение за постулат, то несомненно ваши статьи и размышления на эту тему бесспорны, но на самом деле категоризатор (дерево), которое применяется только для фильтрации и поиска и строится исходя из этих требований - это ошибка.
Моя цель сейчас состоит в том чтобы показать что этот постулат неверен, хотя большая часть сторонников и пользователей деревьев сами этого не понимают.
Давайте привлечем немножко абстракции нам в помощь.
Постановка задачи такова:
1. имеется некоторые сущности, некоторое множество объектов (в нашем случае - строк в таблице), которые нужно подвергнуть категоризации/классификации.
2. Классифируем мы объекты по свойствам. Например - цвет, размер, модель, класс, ассортимент и т.д.
3. Некоторые свойства объектов образуют иерархическое подчинение ВНУТРИ СЕБЯ. Это важный момент. Мы должны понимать что иерархия иерархии рознь - есть иерархия МЕЖКЛАССОВАЯ и есть иерархия ВНУТРИКЛАССОВАЯ. Межклассовая иерархия (у машины есть 4 колеса) превосходно реализуюется в СУРБД связанными таблицами. Внутриклассовая (каталоги в современный файловых системах) - это уже тот вид иерархии вокруг которого разгорелся спор.
И тут уясним для себя важнейший момент:
Внутриклассовая древовидная иерархия существует только в пределах одного свойства объекта! Если вы строите дерево вокруг нескольких свойств объекта, вы поступаете грубо неверно (это верно так же если свойство одно, но недостаточно нормализовано и на самом деле содержит в себе несколько независимых)! В дальнейшем постараюсь прояснить этот момент как можно чётче. Большая часть проблем и неграмотного дизайна древовидных структур связано именно с этим моментом.
Вообще в идеале у справочника объектов должно быть ровно столько НЕЗАВИСИМЫХ древовидных классификаторов, сколько в нём есть полей иерархического свойства.
Рассмотрим тут пример из статьи:
Цитата:
...На первом уровне, как правило, представлены типы товаров, продукции и материалов, на втором уровне производители или бренды, на третьем уровне детализация по группам товаров и продукции, на четвертом уровне детализация по цветам или размерам, на пятом - по техническим характеристикам и т.д....
Нетрудно заметить что в этом примере нарушается тот принцип о котором я сказал - в древовидный классификатор намешана куча совершенно разных свойств объекта! Осюда и все проблемы, которые mazzy ниже совершенно справедливо обозначает. На самом деле это неправильный классификатор. Такие классификации можно выстраивать как дерево в пользовательском интерфейсе (!) но нельзя переносить их на структуру БД!
Остюда на самом деле и вытекает тезис mazzy о том что "иерархическое представление является удобным только для ОДНОГО пользователя". На самом деле это верно только для "неправильных иерархий" - для межклассовых иерархий - т.е. менеджер по закупкам хочет в корне иерархии видеть поле "производитель", но кладовщик хочет видеть в корне иерархии поле "склад". А ведь всё верно! Для них это действительно так, НО ТАКИЕ КЛАССИФИКАТОРЫ ДЕЙСТВИТЕЛЬНО НЕ НУЖНЫ И ЛЕГКО ЗАМЕНЯЮТСЯ ФИЛЬТРАМИ.
Примером правильной классификации является, например, классификация по ассортименту... АССОРТИМЕНТУ И ТОЛЬКО.
Пример из нашего классификатора:
Лакокрасочная продукция / Эмали / Эмали для наружних работ / Пено-фталиевые
В чём тут фокус? Фокус тут в том что уровни правильного классификатора НЕ ПЕРЕСЕКАЮТСЯ. Они не могут быть подменены один другим. Они не могут быть расчлелены на группу полей - внутри подгруппы Эмали не может быть таких же свойств, что в соседних группах.
(*То что я сейчас говорю является своеобразным "правилом нормализации" для древовидных классификаторов. Правило это как правило не может быть соблюдено в полно объеме - *).
Ниже mazzy приводит говорит о различии между иерархией и фильтрацией - ЭТО И ЕСТЬ ТО О ЧЁМ я говорю. Пример с яндексом еще раз подчёркивает это.
На самом деле вокруг нас огромное количество "правильных деревьев" - ассортимент, структурные подразделения чего либо, иерархия в ООП, иерархия оглавления в книгах и т.д. и т.п.
Теперь когда мы разобрались с тем почему не всякий древовидный классификатор является правильным надо уже разбираться с "правильными древовидными классификаторами", и о том нужны ли именно они.
Об этом позже, когда появится время.
P.S.
Надеюсь мысли не слишком сумбурно высказаны, есть куча моментов здесь сказанных, которые по хорошему надо прояснять глубже...