sobolevВы уверены, что смотрите на генеалогическое дерево с той стороны? Корнем, то является один биологический особь, а потомками - его родители. (мое генеалогическое дерево, генеалогическое дерево графа Пупкина, но не генеалогическое дерево барона и баронессы Грачкиных).А как вы из ДЕРЕВА графа Пупкина получите генеалогическое древо баронессы Грачкиной? Если Вы это в принципе не намерены делать, то Ваш опонент, судя по всему, намерен. Вы сначала определитесь по сути спора... :)

mazzy sobolevПо-скольку одноуровневый справочник намного удобнее в использовании. Однако, правда такова, что пользователи голосуют за иерархические группы и отговорить их удается редко.
Может вы расскажете чем именно удобнее и почему они голосуют?
Кто нибудь может внятно изложить свои "ощущения"?Можно, я попытаюсь? :)
Конкретный пример. Имеются организации, с которыми заключаются договора. Договора принимают нумерацию либо по "нашей" системе, либо по системе сторонней организации. Имеется вероятность появления договора с одним и тем же номером (например, №1 - сплошь и рядом) и даже с одной и той же датой, заключенного с разными организациями.
Справочник договоров удобно организовать иерархически. На верхнем уровне организации, на нижнем - договора.

mazzyГотов утверждать, что Пользователи голосуют за дерево только потому, что у них нет развитых средств поиска и классификации информации. Как только у пользователя появляются такие средства, то представление в виде дерева пропадает - пример Каталог Яндекса, Википеида и пример, который я держал "про запас" - del.icio.us с идеей тегов.Такой метод организации, разумеется, имеет право на существование. Но "простое дубовое дерево" иногда оказывается удобнее. Иногда - это тогда, когда нет необходимости в перекрестных ссылках. Следовательно, нет необходиомсти в засорении интерфейса "лишними" управляющими элементами. Кроме того, нет необходимости в декомпозиции дерева каким-то иным способом. Для приведенного мною примера врядли кому-то придет в голову агрегировать инофрмацию по всем договорам №1 без предварительной разбивки на организации. Какой смысл может быть в подобном агрегировании?

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

GaryaСправочник договоров удобно организовать иерархически. На верхнем уровне организации, на нижнем - договора.Немножко более подробно поясню, почему "удобно". Потому что понятия "Договор №1" без привязки к конкретной организации в принципе существовать не может. В то же время может быть организация, взаиморасчеты с которой осуществляются без заключения договора (по счетам). Если сделать равноценным ввод кодов организации и договоров, то появляется возможность ввести договор, не указав организацию. "Деревянная" структура данных запрещает это делать исходя из самой ее организации. В то же время можно ввести новую организацию, не указав никакого договора - это нормально.
Если подобное поведение системы, контролирующей логическую целостность, можно организовать на другом уровне (например, интерфейса), то я ничего против не имею. Только сложновато это будет сделать. Фактически понадобится каким-либо образом "объяснить" системе, чтобы она контролировала, есть ли у организации договора, на которые установлены ссылки, если эту организацию пытаются, например, удалить. То есть, фактически, в систему должна быть встроена "объяснялка", с помощью которой можно было бы легко и просто сказать системе "слушай, система, вот это - ДЕРЕВО! Поняла?" :)

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

Иерархическая организация данных позволяет реализовать еще одну "фичу", существенно упрощающую ввод новой информации. Это НАСЛЕДОВАНИЕ атрибутов. Причем, наследоваться могут как структура атрибутов (без значений), так и сами значения. Это позволяет создать иерархию default-значений на разных уровнях организации данных. Добавление новой записи в дерево на нижних его уровнях может привести к автоматическому "обвешиванию" этой записи несколькими десятками атрибутов, унаследованных от родителей верхних уровней. Что весьма существенно - набор атрибутов у записей может существенно различаться в разных частях дерева, и default-значения могут быть разными, и типы значений могут быть разными. Тем не менее, информация хорошо систематизируется. Можно запускать поиск и по дереву, сложные фильтры и автофильтр (в стиле MS Excel). Эти возможности были реализованы с помощью атрибутов "свойств", и они описаны в моей ставшей уже музейным экспонатом презентации (см. слайды №№16..22). :) В том дереве, которое присутствует на скриншотах, я добавлял новые группы и подгруппы насосов, на ходу задавая правила формирования дочерних записей. Когда добавлял новые записи, они автоматически наследовали неимоверное количество технических характеристик (для некоторых насосов - более 100!), и у меня не занимало много времени ввод этой информации. То, что механизм наследования может существенно ускорить ввод информации и повысить удобство работы - это факт.
Но!!! При такой привязке функциональности к данным дерево может быть ТОЛЬКО ОДНО . Можно, конечно, построить рекомбинированные по иным правилам графы (особенно, если задействованы поля "ссылка на справочник"), но такие графы можно открывать только на просмотр (например, использовать только для отчетов). Ввод информации - только через одно и то же дерево, поскольку правила ввода задаются по-разному на разных его узлах. Я, там, правда, пытался это ограничение обойти (см.слайд №22) с помощью т.н. "проекции на справочник" - линейное представление поддерева, в котором "свойства" превращаются в "поля". И хотя сделать это удалось (хотя и сильно тормозило, когда введенные в линейное представление записи приводили к образованию новых "виноградных гроздей" в иерархической структуре - реально данные хранились именно в иерархии), я не считаю это очень удачной идеей. Приходится заранее жестко оговорить правила формирования поддерева на всех уровнях, которые приходится вручную реализовывать в instead-триггерах, "раскладывающие" добавленную или отредактированную информацию по дереву. Могу сказать, что 70% текста такого триггера составляют диагностические сообщения о нарушении правил формирования дерева. Пользователи, привыкшие представлять информацию именно линейно (как простая плоская таблица) и не привыкшие к строгому соблюдению заданных правил ввода, сильно нервничали, когда система не давала им на протяжении 20 минут ввести новую запись до тех пор, пока они не соблюдут все требования. При вводе в дерево и софт работает на порядки быстрее, и некоторые многие правила "интуитивно" и "вынуждено" соблюдаются пользователями "на автомате". Заказчик, который меня фактически принудил к разработке плоских "проекций", сам через некоторое время пришел к выводу, что иерархия с обобщенными правилами наследования гораздо удобнее. Потому что то и дело выяснялось, что оговоренные рание правила нужно изменить или дополнить - когда появлялись новые подгруппы оборудования. В таких случаях приходилось вносить изменения в текст istead-триггеров. При работе же непосредственно через дерево достаточно было завести новые подгруппы в новых узлах поддерева и задать для них специфические правила ввода на дочерние уровни. Сделать это мог любой пользователь, наделенный соответствующими правами, без обращения к IT-специалисту.
Таким образом, я пришел к выводу - либо "наследование со всеми вытекающими из него плюсами для удобства ввода + только один базовый граф, через который осуществляется ввод информации", либо "множество графов при отсутствии наследования". Кому что удобнее, пусть решает сам.

mazzy"Справочник договоров удобно организовать иерархически" только для двухсторонних договоров. Такой справочник будет чертовски неудобен для многосторонних договоров.Ок, согласен. Для реализации многосторнних договоров можно использовать набор "ссылок на справочник". То есть, создаются два разных справочника - "организации" и "договора". Для договора поле "стороны" имеет тип "множество значений из справочника" (см. последнюю запись в списке на слайде №14). Когда между справочниками создана связь, они представляются в виде подчиненного и подчиняемого справочника. Визуализация пары таких справочников возможна двумя способами, какой наиболее удобен в каком случае - выбирает юзер (см.слайд №15). Либо вводятся сразу договора, и для каждого из них галочкой помечаются выбранные из справочника стороны (вариант 1). Либо сначала открывается спраочник контрагентов, для него открывается подчиненный - договора, и в окне справочника "договорах" автоматически отфильтровываются только те, которые имеют отношение к выделенной в окне "контрагентов" организации (вариант 2). А при добавлении новых договоров по варианту 2, в поле "стороны" автоматически проставляется текущая (для справочника "контрагенты") организация без возможности ее оттуда убрать (это поле вообще скрывается, чтобы никого не смущать). Фактически, это функционал "древовидности", который можно "включать" и "выключать" в зависимости от ситуации. Он дает одни преимущества, но лишает других. Он лишает автоматического наследования структур данных и их значений, а также других правил ввода информации, например, требований уникальности некоторых полей договора (номера с датой) в пределах одной организации.

mazzy GaryaЭто НАСЛЕДОВАНИЕ атрибутов.
Наследование атрибутов происходит не из-за иерархии.
А из-за того, что у записи устанавливается значение поля-классификатора.
Наследование может происходить и без иерархии.Секундочку... Что-то я эту мысль не понял. Можно разжевать? Может быть, на конкретном приммере? Открываем слайд №18 и видим:
1. Содержимое части номенклатурного справочника, а именно, части группы "двигатели". Для группы "двигатели" задан набор атрибутов (без значений!), сами атрибуты также имеют иерархическую организацию. Мы видим, что все подгруппы группы "двигатели" их НАСЛЕДУЮТ . А именно, группы характеристик "Базовые характеристики двигателей", "Дополнительные характеристики двигателей", "Посадочные характеристики" и "Специальные характеристики". В частности, из группы характеристик "Базовые характеристики двигателей" все дочерние (а также "внучатые" и "правнучатые" и т.д.) подгруппы и элементы наследуют характеристики "Взрывозащита", "Монтажное исполнение", "Мощность двигателя", "Напряжение питания", "Обороты двигателя" - что очень важно, БЕЗ КОНКРЕТНЫХ ЗНАЧЕНИЙ этих атрибутов.
2. Подгруппа "Двиг. 7,5 квт" содержит всё то же самое, но для атрибута "Мощность двигателя" выставлено конкретное значение - 7.5 кВт, которое будет наследоваться "насмерть" (без возможности внести изменение на низлежащих уровнях). Одновременно в группе "Специальные характеристики" характеристика "Скольжение" приняла значение "Ложь". Это значение - наиболее часто встречающиеся для тех двигателей, которыми мы торгуем с мощностью 7.5 кВт (99%). И мы специально проставили значение этой характеристики, чтобы на низлежащих уровнях этот атрибут автоматически принимал значение "ложь", когда мы будем туда добавлять записи. Но, тем не менее, это значение НЕ ЗАШИТО "НАСМЕРТЬ". То есть, у любой дочерней подгруппы можно изменить это значение на "истина" - и дальше уже будет наследоваться "истина". Можно также у одних элементов одной подгруппы иметь разные характеристики скольжения.
3. Дочерними для подгруппы "Двиг. 7,5 квт" является несколько подподгрупп, в частности выделенная синим фоном "текущая запись" "Двиг. 7,5 /3000 общепромышл. Лапы 220/380В 50Гц", персонально для которой выставлены значения характеристик: "Взрывозащита" = "Общепромышленные"; "Монтажное исполнение" = "Лапы"; "Напряжение питания" = "220/380В, 50гц"; "Обороты двигателя" = 3000. При добавлении в эту подподгруппу новых записей они унаследуют не только структуру атрибутов, но и еще 5 предварительно заданных значений.

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

Теперь о фильтрации и поиске... Взгляните на скриншот. Видите там рядом с атрибутом "Взрывозащита" малень серенькую кнопочку с треугольничком? Если по ней щелкнуть, выпадет список для включения автофильтра, подобно тому, как это делается в Excel. Аналогичная кнопочка имеется для полей "Наименование" или "Базовая единица измерения" (поля отличаются от свойств тем, что эти атрибуты задаются для всех записей одного справчоника и не могут изменять свой состав в разных ветвях иерархии). На панели инструментов имеются кнопочки с изображением воронки, с помощью которой можно задать сложный фильтр по совокупности свойств и полей, объединяемых разными логическими условиями.
Нажав Ctrl+F или щелкнув по кнопочне с биноклем в панели инструментов, можно задать параметры поиска по отфильтрованным записям.
Если в панели инструментов щелкнуть по пиктограммке слва от бинокля, то можно увидеть меню параметров отображения справочника (оно есть на слайде №15). Если в нем убрать галочку с параметра "Показывать только прямых наследников", то в правой части можно увидеть содержимое всего поддерева, вершиной которого является подгруппа "Двиг. 7,5 квт". Включая или отключая отображение групп и/или простых элементов, можно видеть в этом поддереве всё вперемешку, либо только "листья" поддерева, либо только НЕ-листья.
Есть еще права доступа и блокировки. На уровень групп и подгрупп "простые смертные не имеют права добавлять новых записей без согласования с руководителями своих подразделений. Точнее, новые группы и подгруппы могут добавить только руководители подразделений. Они же для них задают "правила игры".
Как всё это можно сделать без реальной иерархии, я что-то плохо представляю. Каким образом можно имитировать работу этих механизмов только на одном задании значения поля-классификатора? Что немаловажно - задание "правил игры" должно быть доступно руководителям подразделений - НЕ IT-шникам!

Чернышев Андрей ЛеонидовичМне кажется Вы, Garya, не точны в рассуждениях про "организации" и "договора". Обычная навигация по схеме данных (в том числе и при связи М:М)
Организация - С которой заключен - Договор
решает "задачу" безо всякого "дерева". Можно, конечно, как я уже говорил, разглядеть "дерево" в любой схеме данных: Документ -> Запись документа, и т.д. Но, по сути, обычные навигация и фильтрация решают любые вопросы, независимо от формы представления данных, хранящихся в БД (почти наверняка либо в "реляционной", либо в "объектной").Речь идет не только о струкутре данных и о фильтрации. Каким образом обеспечить, например, возможность добавления договора №1 с привязкой к организации "АБВГ" потому что раньше договора с подобным номером у этой организации не было; и одновременно запретить добавление договора №1 с привязкой к организации "ДЕЖЗ", потому что такой договор с этой организацией уже был? Эта задача не связана с навигацией. Она связана с заданием дополнительных правил структурирования информации, ограничений целостности.
Я понимаю, что решить ее в данном конкретном случае можно, например, с помощью триггера. А в общем случае как сделать? Причем, так, чтобы каждый раз не обращаться к IT-специалисту. Прочитайте мой предыдущий пост - там есть вариант реализации именно этой задачи. И реализуется он только на структуре данных "дерево".