Говорят, что IB плохо работает с деревьями...?

← →
KIR (2003-01-30 21:17) [0]

Народ, я тут начал делать очередной проект, и в нем есть такая табличка:

ID | FieldName | ParentID

Уровень вложенности не известен, но я думаю, что не перевалит за 5-7. Записей в таблице будет около 500-700.

В одной ветке, наткунлся на чье-то высказывание о сабже. Сам я в IB с деревьями еще не разу не работал. Если у кого есть опыт, поделитесь. А то щас сделаешь а потом окажется "как всегда"..

← →
Ihor Osov'yak (2003-01-30 21:26) [1]

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

Зы - похожие структуры использую довольно часто.

← →
Jeer (2003-01-30 21:26) [2]

1.А что, стандартный SQL стал поддерживать иерархические структуры ?

2.Для ЛЮБОЙ СУБД приведенные цифры не являются критичными.

3.Тем более, если пользоваться диалектами, UDF, ХП.

← →
Ihor Osov'yak (2003-01-30 21:31) [3]

2 Jeer © (30.01.03 21:26)
> А что, стандартный SQL стал поддерживать иерархические структуры ?

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

← →
KIR (2003-01-30 21:57) [4]

К вопросу о модели: у меня это справочник, который представлен с помошью TreeView

← →
Sergey Masloff (2003-01-30 22:28) [5]

KIR ©
>К вопросу о модели: у меня это справочник, который представлен >с помошью TreeView
Да по фигу справочник или нет. У меня вот в текущем проекте половина таблиц иерархические. Есть и справочник 80000 записей полностью иерархический. Есть и не справочники. Проблем только нет ;-)

← →
Jeer (2003-01-30 22:46) [6]

>Ihor Osov"yak © (30.01.03 21:31)
>Дык это реляционная модель иерархической структуры... В чем >проблема?

Конечно, особой проблемы нет.
Только надо понимать (я KIR-у) о чем речь идет.
Если о "стандартном" - то, поддержки нет (во всяком случае нет универсального решения).
Если о диалектах - везде свои особенности.

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

KIR-у стоит заглянуть на www.ibase.ru

← →
Sergey13 (2003-01-31 08:32) [7]

2KIR © (30.01.03 21:17)
>В одной ветке, наткунлся на чье-то высказывание о сабже
Наверное это был я в ветке про структуру данных. Но я не говорил что плохо работает, я говорил плохо с ними работать. Не удобно, то есть. В оракле например у SQL есть спец примочка - CONNECT BY PRIOR - сам сервер ищет все записи ветки (хоть вверх хоть вниз). В ИБ такого нет - приходится все делать самому через ХП. Отсюда и неудобство.

← →
Digitman (2003-01-31 09:01) [8]

>KIR

IB ничуть не хуже справляется с этой задачей, нежели иные СУБД

Ты лучше конкретизируй требуемые бизнес-правила для будущего дерева и его узлов, хотя бы :

- "дерево" это или "кустарник";
- требования по уникальности имен узлов;

Это важно.

← →
jocko (2003-01-31 10:13) [9]

возможно вопрос о трудностях касается способности сервера поддерживать рекурсию или точнее ограничение по количеству рекурсивных вызовов, т.е. например необходимо найти всех Parent для конечного узла, кроме того, необходимо учесть где хранить промежуточные данные... хотя это все решаемо.
Кстати, можно хранить данные в двух таблицах
T1 (id, FieldName)
T1 (ChildId, ParentId, SomeFieldThatDescriptReference)

← →
ATR (2003-01-31 10:16) [10]

80000 записей в справочнике - эт конечно не новость... Но вот пихать это в дерево... ??? А как юзер будет по нему прыгать... Он не Тарзан :) Попробуй в дереве разыщи чё нить, если оно одно как Шервудский лес...
Моё баловство с деревьями привело к возврату к табличному представлению... Так что ... не слишком увлекайтесь, парни ;)

← →
Delirium^.Tremens (2003-01-31 10:28) [11]

Не IB плохо работает с "деревьями", а "деревья" плохо умеют работать с IB.
Афоризм, однако :-)

← →
Jeer (2003-01-31 10:37) [12]

ATR (31.01.03 10:16)

Любое представление данных имеет право на существование, если оно удобно клиенту для понимания(поиска)по классификации.

Основная проблема, с которой сталкиваются начинающие, да и не очень, разработчики - это смешивание разнородных сущностей в дереве.
В этом случае, действительно бегать глазками-ручками по дереву из 80 тыс элементов занимательно.
На мой вгляд, надо обязательно вводить понятие категорий сущностей и присваивать надлежащим узлам.
Например, категория производитель с элементом IBM может
появиться и в серверах и в винтах.

В 1С сделана попытка (абсолютно неудачная, IMHO) реализовать это через свойства.

← →
Vladimir (2003-01-31 13:19) [13]

Есть хорошая статья - деревья в SQL , лежит на
http://sdm.viptop.ru/articles/sqltrees.html - описано, как избежать рекурсии при проектировании древовидных структур. Рекомендую.

← →
kaif (2003-01-31 14:25) [14]

На IB очень лихо можно писать обработку дереыьев. Я лично придумал такой подход:
1. У меня есть процедура, возвращающая данный элемент и всех предков данного элемента.
2. Есть процедура, запрашивающая для всех элементов таблицы с помощью первой процедуры всех предков и формирующая, таким образом, набор всех сочетаний предок-потомок.
3. Далее, объединяя этот набор с таблицей данных, я совершенно обычным SELECT-ом с INNER JOIN получаю любые выборки всех "дочерних и их потомков", если это нужно. И никаких рекурсий.

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

← →
KIR (2003-01-31 18:54) [15]

Мне кажется, что в некоторых Ваших, народ, ответах проскальзывает некое нежелание использовать рекурсию... а что в этом плохого, учитавая мой случай (я имею ввиду неглубокий уровень вложенности). Можно даже рекурсивно строить дерево не через ХП, а стороне клиента (я у себя попробовал - разницы по времени нет). Вот премер (для простоты я убрал все try... finally)
procedure BuildTree(Root: TTreeNode); var Node: TTreeNode; DS: tpFIBDataSet; S: String; begin If Root = nil then S := "PARENTID is null" else S := "PARENTID = "+IntToStr(Integer(Root.Data)); DS := tpFIBDataSet.Create(nil); DS.SQLs.SelectSQL.Add("SELECT"); DS.SQLs.SelectSQL.Add("*"); DS.SQLs.SelectSQL.Add("FROM"); DS.SQLs.SelectSQL.Add("RASH_S"); DS.SQLs.SelectSQL.Add("WHERE"); DS.SQLs.SelectSQL.Add(S); DS.SQLs.SelectSQL.Add("ORDER BY"); DS.SQLs.SelectSQL.Add("NAME"); DS.Transaction := DM1.SelectTS; DS.Open; DS.First; While not DS.Eof do begin Node := TreeView2.Items.AddChildObject(Root,DS["Name"]+" ("+IntToStr(DS["ID"])+")", Pointer(Integer(DS["ID"]))); BuildIBTree(Node); DS.Next; end; end;

← →
Sergey Masloff (2003-02-01 11:16) [16]

ATR (31.01.03 10:16)
>80000 записей в справочнике - эт конечно не новость... Но вот пихать это в дерево... ??? А как юзер будет по нему прыгать...

Не понял вопроса? А по обычному справочнику он как прыгает? Во-первых, в 90% справочников открывается не от корня а от определенного узла. Скажем, если пользователь хочет увидеть справочник цветов то я ему и открываю с узла "Цвета".

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

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

← →
kaif (2003-02-01 15:08) [17]

2 Sergey Masloff (01.02.03 11:16)
Как Вам нравится такое дерево?

Товары
Спиртные напитки
Крепкие спиртные напитки
Водка
Кристалл
0.75
"Гжелка"

Или может так правильно?:

Товары
Спиртные напитки
0.75
Кристалл
Водка
Гжелка

А я видел такое (в 1С):

Товары
Обувь
Сапоги
Сапоги кирза-юфть
Женские
Коричневые
39 размер
(И все в таком духе...)
Брак
Колготки
Возврат в кассу от 01.03.1998
Склад
остаток на 11.10.1998

(Это все в справочнике "Товары")

>При организации справочника таким образом резко сокращается >число пользуемых таблиц - если без дерева мне бы понадобилась >не одна сотня таблиц только для справочников.

Это и называется перекладывать свои проблемы на плечи юзера.
А потом он приходит и говорит:

Хочу отчет о продажах такого вида:
Литраж, л 0.5 0.75 1.0 1.25
Продажи, р ... .... ... ...

Или хочу остаток на складе видеть:

Размер обуви: 39 40 41 42 43
Остаток: .. .. .. .. ..

А у него в дереве все это на разных уровнях и как попало введено.

← →
Sergey Masloff (2003-02-01 18:41) [18]

kaif ©
Стоп-стоп. Мухи отдельно котлеты отдельно. По справочникам никаких остатков быть не может. Это ерунда. Есть таблицы "оперативные" И в них
ID Количество Код товара И так далее
1 + 20 123467 (Водка 0.75 Гжелка) И так далее
2 - 50 8907340658 (Тапочки 46 разм.) ....
3 + 25 8745694 (Водка 0.5 Праздничная)

И при чем здесь иерархия справочника??? Справочник возникает на этапе ввода "проводок" когда указывается код товара.
Так что этот Ваш довод отвергаю.
И повторюсь - при этом справочник у меня ОДИН. То есть и при вводе литража, класса продукции, страны изготовителя, валюты и так далее используется один и тот же объект. Только отображает он все время разные ветки дерева. Утверждается что это очень удобно. Если есть доводы почему это неудобно - в студию ;-)

Если про деревья не в справочниках то они тоже иногда нужны. Но конечно не в таком виде как Вы привели пример.

← →
kaif (2003-02-01 19:19) [19]

2 Sergey Masloff (01.02.03 18:41)

Юзер, получая в руки дерево, сразу начинает рассчитывать на перспективу "глубокого анализа". Именно поэтому он начинает плодить иерархии типа
Товары
Спиртные напитки
Крепкие спиртные напитки
Водка
Кристалл
0.75
"Гжелка"

А не как-нибудь по-проще типа:

Товары
Водка "Гжелка" 0,75, Кристалл

И он при этом надеется, что программист сумеет вытащить отчеты, о которых я говорил (например, объемы продаж с группировкой по марке, литражу или производителю).
SQL придумывался, как отчетно-ориентированное мощное средство. Если же все запихать в дерево, тогда значительная часть того, что может SQL пропадает из-за нестрогой организации данных.
Именно нестрогая организация приводит к тому, что в справочник товаров юзер сдуру может ввести позицию "Возврат разного типа сапогов от 01.01.1999" или еще какую-нибудь ересь. Я не придумываю. Я такое видел собственными глазами и не раз.

Другое дело, что программисту лень плодить сотни таблиц или он не знает, как это автоматизировать. Но это проблема программиста. И эта проблема решаема. Хотя и не так, чтобы запросто.

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

← →
Sergey Masloff (2003-02-02 00:04) [20]

kaif ©
Все же вы проблему сводите в неправильное русло. Отчеты с группировками все равно на оперативной базе никто от хорошей жизни делать не станет. Есть мухи и есть котлеты. Есть OLAP и есть OLTP и пока нет способа сделать это хорошо и в одном флаконе. Я только изложил реальное решение реализованное в системе уровня предприятия с тысячей одновременно работающих пользователей. Проблем описанных Вами не возникает. Совсем. То ли пользователи умные то ли... на этом мысль останавливается ;-)

Подчеркну: программисту плодить сотни таблиц не лень. Как это автоматизировать он тоже знает ;-) Просто нет в этом смысла. По крайней мере в нашем случае.

← →
kaif (2003-02-02 01:05) [21]

2 Sergey Masloff (02.02.03 00:04)
Возможно мы говорим о разных вещах или плохо понимаем друг друга. Возможно в Вашем случае использование дерева оправдано. Не зная задачи, трудно сказать. Еще раз повторюсь, я всего лишь против идеи, что дерево - наилучший способ организации справочников. Просто часто приходится здесь читать постинги типа "Как мне сделать древовидный справочник, как в 1С ?". И никто не задается вопросом, а правильно ли делать такие справочники вообще. Спорить я не хочу, тем более, что у Вас уже есть готовое решение. У меня тоже есть готовое решение, прямо противоположного сорта. Я придерживаюсь того мнения, что существуют деревья классов, но не деревья объектов. Тогда атрибуты и сущности не начинают подменять друг друга. Правда у меня объекты низших классов наследуют атрибуты старших, в частности атрибут ID. Только так решаются проблемы объединения объектов в метаклассы типа "Товары" или "Контрагенты". Надеюсь скоро я опубликую это решение и многое смогу прояснить для уважаемой публики.
Считайте, что я просто предвзят и извините за настырность...

← →
Sergey Masloff (2003-02-02 09:59) [22]

kaif ©
>часто приходится здесь читать постинги типа "Как мне сделать >древовидный справочник, как в 1С ?".
Я, честно говоря, не видел древовидного справочника в 1С и у меня все более крепнет мысль что мы говорим о разных вещах...

>Считайте, что я просто предвзят и извините за настырность...
Я, вобщем-то, не вижу причин извиняться. Естественно, для каждой задачи хороши свои методы. Так что когда и дерево полезно, когда и наоборот ;-)

← →
Sergey13 (2003-02-03 09:30) [23]

2Sergey Masloff (02.02.03 09:59)
ИМХО, кайф прав. При вашей организации справочника возникает много неопределенностей от ввода юзеров. Например, вы резонно полагаете что для водки главное это то что она Товар->Спиртные напитки->водка. Юзер же может поставить во главу угла цвет (например) Бесцветные->Жидкие->Крепкие->Спиртные->Водка. При этом естественно породится несколько "водок" в справочнике, что недопустимо. А так как юзер НИКОГДА(по вашему описанию) не видит ВСЕГО справочника (только отдельные ветки) то в этом его и винить то нельзя.
В общем, мне нажется что ваш справочник нуждается в другом справочнике.
Соглашусь лишь с тем что "Естественно, для каждой задачи хороши свои методы"

← →
Sergey Masloff (2003-02-03 10:21) [24]

Sergey13 ©
>так как юзер НИКОГДА(по вашему описанию) не видит ВСЕГО справочника
Ну, почему... может увидеть. Если из меню вызовет "Основной справочник". Только на внесение данных в справочник прописан регламент. И пользователь Вася при всем желании ничего никогда в него не внесет. А внесет уполномоченный на то пользователь Петя, который за правильность внесенных данных отвечает персонально, причем на все что он вводил и изменял есть история, "у меня все ходы записаны" (с)

Причем я не понимаю что мешает пользователю Васе в "плоской" схеме внести товары "Бесцветная жидкая водка", "Безалкогольная водка" и так далее. Так что проблем с отчетами и так далее все равно не решается при этом.

Вобщем, пользуйтесь деревьями - просто, удобно, функционально! (реклама)

← →
Sergey13 (2003-02-03 10:57) [25]

2Sergey Masloff (03.02.03 10:21)
>Ну, почему... может увидеть. Если из меню вызовет "Основной справочник".
И испытает истинное наслаждение разбираясь в дебрях этого дерева с тысячами веток. 8-)
Древесность/плоскостность тут не играет роли. Мне не нравится сам принцип ОДНОГО справочника на все. Уж очень сложно совместить несовместимое - и цвет и твердость например.

>А внесет уполномоченный на то пользователь Петя
Как показывает практика (моя по крайней мере) - если что то можно интерпретировать по разному, найдется кто-то кто поймет все по своему, и при этом НЕПРАВИЛЬНО. Причем выявится это через несколько времени после начала эксплуатации, когда уже данных введено... ого-го. Да и Петя тоже не бог, и даже не его апостол. 8-)

>что мешает пользователю Васе в "плоской" схеме внести товары "Бесцветная жидкая водка",
Помешает (по крайней мере оччччень затруднит) то, что это три справочника. Первые два (цвет и жидковатость 8-) по идее очень маленькие. Ошибиться с вводом ГОРАЗДО труднее. Да и третий (товар) в силу его "плоскостности" контролировать проще.

← →
Sergey Masloff (2003-02-03 11:41) [26]

Sergey13 © (03.02.03 10:57)
>>Ну, почему... может увидеть. Если из меню вызовет "Основной справочник".
>И испытает истинное наслаждение разбираясь в дебрях этого дерева с тысячами веток. 8-)

Да ну прям... Это ж как индекс - пара щелчков мыши и вы в нужном подмножестве. Кроме того, есть уже упомянутый мной поиск ;-)

>Уж очень сложно совместить несовместимое - и цвет и твердость например.
Да чего там сложного? SHORTNAME, FULLNAME и CODE для 99% достаточно в 99% случаев. Тем более, некоторые ветки "дерева" являются "заголовками" "тело" которых вынесено в отдельную таблицу

>>А внесет уполномоченный на то пользователь Петя
>Как показывает практика... <skip> Да и Петя тоже не бог, и даже не его апостол. 8-)
Но наличие ПЕРСОНАЛЬНОЙ ответственности просто чудеса с людьми творит. Серьезно.

>>что мешает пользователю Васе в "плоской" схеме внести товары "Бесцветная жидкая водка",
>Помешает (по крайней мере оччччень затруднит) то, что это три справочника. Первые два (цвет и жидковатость 8-) по идее очень маленькие. Ошибиться с вводом ГОРАЗДО труднее. Да и третий (товар) в силу его "плоскостности" контролировать проще.

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

← →
Sergey13 (2003-02-03 11:56) [27]

2Sergey Masloff (03.02.03 11:41)
>все равно нужно хранить связи водка->жидкость->цвет
А на вкус и цвет, как известно ... 8-) Сколько людей - столько мнений.

← →
Sergey Masloff (2003-02-03 12:04) [28]

Sergey13 © (03.02.03 11:56)
>>все равно нужно хранить связи водка->жидкость->цвет
>А на вкус и цвет, как известно ...
Хорошо получилось... Аж настроение поднялось :-)

← →
AZDesign (2003-02-05 21:38) [29]

Прекрасно работают деревья в IB и наоборот. Я использую по 3-4 дерева в одной таблице, бывает до 200-300 листиков на одной ветке.
Проблемы только с перетаскиванием, когда тащишь и упираешся в край окна. Количество уровней в дереве достигает 15-20.
Есть некоторые проблемы при организации структуры когда несколько деревьев в одной таблице, но поработаешь сам поймешь.

Говорят, что IB плохо работает с деревьями...? Найти похожие ветки