| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Говорят, что IB плохо работает с деревьями...?
KIR © (2003-01-30 21:17:00)Народ, я тут начал делать очередной проект, и в нем есть такая табличка:
ID | FieldName | ParentID
Уровень вложенности не известен, но я думаю, что не перевалит за 5-7. Записей в таблице будет около 500-700.
В одной ветке, наткунлся на чье-то высказывание о сабже. Сам я в IB с деревьями еще не разу не работал. Если у кого есть опыт, поделитесь. А то щас сделаешь а потом окажется "как всегда"..
AZDesign (2003-02-05 21:38:00) [1]Прекрасно работают деревья в IB и наоборот. Я использую по 3-4 дерева в одной таблице, бывает до 200-300 листиков на одной ветке.
Проблемы только с перетаскиванием, когда тащишь и упираешся в край окна. Количество уровней в дереве достигает 15-20.
Есть некоторые проблемы при организации структуры когда несколько деревьев в одной таблице, но поработаешь сам поймешь.
Sergey Masloff (2003-02-03 12:04:00) [2]Sergey13 © (03.02.03 11:56)
>>все равно нужно хранить связи водка->жидкость->цвет
>А на вкус и цвет, как известно ...
Хорошо получилось... Аж настроение поднялось :-)
Sergey13 (2003-02-03 11:56:00) [3]2Sergey Masloff (03.02.03 11:41)
>все равно нужно хранить связи водка->жидкость->цвет
А на вкус и цвет, как известно ... 8-) Сколько людей - столько мнений.
Sergey Masloff (2003-02-03 11:41:00) [4]Sergey13 © (03.02.03 10:57)
>>Ну, почему... может увидеть. Если из меню вызовет "Основной справочник".
>И испытает истинное наслаждение разбираясь в дебрях этого дерева с тысячами веток. 8-)
Да ну прям... Это ж как индекс - пара щелчков мыши и вы в нужном подмножестве. Кроме того, есть уже упомянутый мной поиск ;-)
>Уж очень сложно совместить несовместимое - и цвет и твердость например.
Да чего там сложного? SHORTNAME, FULLNAME и CODE для 99% достаточно в 99% случаев. Тем более, некоторые ветки "дерева" являются "заголовками" "тело" которых вынесено в отдельную таблицу
>>А внесет уполномоченный на то пользователь Петя
>Как показывает практика... <skip> Да и Петя тоже не бог, и даже не его апостол. 8-)
Но наличие ПЕРСОНАЛЬНОЙ ответственности просто чудеса с людьми творит. Серьезно.
>>что мешает пользователю Васе в "плоской" схеме внести товары "Бесцветная жидкая водка",
>Помешает (по крайней мере оччччень затруднит) то, что это три справочника. Первые два (цвет и жидковатость 8-) по идее очень маленькие. Ошибиться с вводом ГОРАЗДО труднее. Да и третий (товар) в силу его "плоскостности" контролировать проще.
Ни фига не помешает. И вообще, плоская схема ничего не упрощает - все равно нужно хранить связи водка->жидкость->цвет и так далее и просто дерево получается развернутым на несколько таблиц. А так как таких таблиц (у меня) были бы много тысяч то я считаю их плождение неправильным. Кроме того, на одной таблице значительно проще обеспечить фильтрацию для отображения данных пользователям. Так, специалисту мед. управления на фиг не нужен справочник средств транспорта а другим так же не нужен справочник заболеваний. И раздавать видимость справочников я могу в одном месте. И это только одно из удобств ;-)
Sergey13 (2003-02-03 10:57:00) [5]2Sergey Masloff (03.02.03 10:21)
>Ну, почему... может увидеть. Если из меню вызовет "Основной справочник".
И испытает истинное наслаждение разбираясь в дебрях этого дерева с тысячами веток. 8-)
Древесность/плоскостность тут не играет роли. Мне не нравится сам принцип ОДНОГО справочника на все. Уж очень сложно совместить несовместимое - и цвет и твердость например.
>А внесет уполномоченный на то пользователь Петя
Как показывает практика (моя по крайней мере) - если что то можно интерпретировать по разному, найдется кто-то кто поймет все по своему, и при этом НЕПРАВИЛЬНО. Причем выявится это через несколько времени после начала эксплуатации, когда уже данных введено... ого-го. Да и Петя тоже не бог, и даже не его апостол. 8-)
>что мешает пользователю Васе в "плоской" схеме внести товары "Бесцветная жидкая водка",
Помешает (по крайней мере оччччень затруднит) то, что это три справочника. Первые два (цвет и жидковатость 8-) по идее очень маленькие. Ошибиться с вводом ГОРАЗДО труднее. Да и третий (товар) в силу его "плоскостности" контролировать проще.
Sergey Masloff (2003-02-03 10:21:00) [6]Sergey13 ©
>так как юзер НИКОГДА(по вашему описанию) не видит ВСЕГО справочника
Ну, почему... может увидеть. Если из меню вызовет "Основной справочник". Только на внесение данных в справочник прописан регламент. И пользователь Вася при всем желании ничего никогда в него не внесет. А внесет уполномоченный на то пользователь Петя, который за правильность внесенных данных отвечает персонально, причем на все что он вводил и изменял есть история, "у меня все ходы записаны" (с)
Причем я не понимаю что мешает пользователю Васе в "плоской" схеме внести товары "Бесцветная жидкая водка", "Безалкогольная водка" и так далее. Так что проблем с отчетами и так далее все равно не решается при этом.
Вобщем, пользуйтесь деревьями - просто, удобно, функционально! (реклама)
Sergey13 (2003-02-03 09:30:00) [7]2Sergey Masloff (02.02.03 09:59)
ИМХО, кайф прав. При вашей организации справочника возникает много неопределенностей от ввода юзеров. Например, вы резонно полагаете что для водки главное это то что она Товар->Спиртные напитки->водка. Юзер же может поставить во главу угла цвет (например) Бесцветные->Жидкие->Крепкие->Спиртные->Водка. При этом естественно породится несколько "водок" в справочнике, что недопустимо. А так как юзер НИКОГДА(по вашему описанию) не видит ВСЕГО справочника (только отдельные ветки) то в этом его и винить то нельзя.
В общем, мне нажется что ваш справочник нуждается в другом справочнике.
Соглашусь лишь с тем что "Естественно, для каждой задачи хороши свои методы"
Sergey Masloff (2003-02-02 09:59:00) [8]kaif ©
>часто приходится здесь читать постинги типа "Как мне сделать >древовидный справочник, как в 1С ?".
Я, честно говоря, не видел древовидного справочника в 1С и у меня все более крепнет мысль что мы говорим о разных вещах...
>Считайте, что я просто предвзят и извините за настырность...
Я, вобщем-то, не вижу причин извиняться. Естественно, для каждой задачи хороши свои методы. Так что когда и дерево полезно, когда и наоборот ;-)
kaif (2003-02-02 01:05:00) [9]2 Sergey Masloff (02.02.03 00:04)
Возможно мы говорим о разных вещах или плохо понимаем друг друга. Возможно в Вашем случае использование дерева оправдано. Не зная задачи, трудно сказать. Еще раз повторюсь, я всего лишь против идеи, что дерево - наилучший способ организации справочников. Просто часто приходится здесь читать постинги типа "Как мне сделать древовидный справочник, как в 1С ?". И никто не задается вопросом, а правильно ли делать такие справочники вообще. Спорить я не хочу, тем более, что у Вас уже есть готовое решение. У меня тоже есть готовое решение, прямо противоположного сорта. Я придерживаюсь того мнения, что существуют деревья классов, но не деревья объектов. Тогда атрибуты и сущности не начинают подменять друг друга. Правда у меня объекты низших классов наследуют атрибуты старших, в частности атрибут ID. Только так решаются проблемы объединения объектов в метаклассы типа "Товары" или "Контрагенты". Надеюсь скоро я опубликую это решение и многое смогу прояснить для уважаемой публики.
Считайте, что я просто предвзят и извините за настырность...
Sergey Masloff (2003-02-02 00:04:00) [10]kaif ©
Все же вы проблему сводите в неправильное русло. Отчеты с группировками все равно на оперативной базе никто от хорошей жизни делать не станет. Есть мухи и есть котлеты. Есть OLAP и есть OLTP и пока нет способа сделать это хорошо и в одном флаконе. Я только изложил реальное решение реализованное в системе уровня предприятия с тысячей одновременно работающих пользователей. Проблем описанных Вами не возникает. Совсем. То ли пользователи умные то ли... на этом мысль останавливается ;-)
Подчеркну: программисту плодить сотни таблиц не лень. Как это автоматизировать он тоже знает ;-) Просто нет в этом смысла. По крайней мере в нашем случае.
kaif (2003-02-01 19:19:00) [11]2 Sergey Masloff (01.02.03 18:41)
Юзер, получая в руки дерево, сразу начинает рассчитывать на перспективу "глубокого анализа". Именно поэтому он начинает плодить иерархии типа
Товары
Спиртные напитки
Крепкие спиртные напитки
Водка
Кристалл
0.75
"Гжелка"
А не как-нибудь по-проще типа:
Товары
Водка "Гжелка" 0,75, Кристалл
И он при этом надеется, что программист сумеет вытащить отчеты, о которых я говорил (например, объемы продаж с группировкой по марке, литражу или производителю).
SQL придумывался, как отчетно-ориентированное мощное средство. Если же все запихать в дерево, тогда значительная часть того, что может SQL пропадает из-за нестрогой организации данных.
Именно нестрогая организация приводит к тому, что в справочник товаров юзер сдуру может ввести позицию "Возврат разного типа сапогов от 01.01.1999" или еще какую-нибудь ересь. Я не придумываю. Я такое видел собственными глазами и не раз.
Другое дело, что программисту лень плодить сотни таблиц или он не знает, как это автоматизировать. Но это проблема программиста. И эта проблема решаема. Хотя и не так, чтобы запросто.
Я всего лишь призываю не принимать окончательного решения навсегда в пользу деревьев в справочниках.
Sergey Masloff (2003-02-01 18:41:00) [12]kaif ©
Стоп-стоп. Мухи отдельно котлеты отдельно. По справочникам никаких остатков быть не может. Это ерунда. Есть таблицы "оперативные" И в них
ID Количество Код товара И так далее
1 + 20 123467 (Водка 0.75 Гжелка) И так далее
2 - 50 8907340658 (Тапочки 46 разм.) ....
3 + 25 8745694 (Водка 0.5 Праздничная)
И при чем здесь иерархия справочника??? Справочник возникает на этапе ввода "проводок" когда указывается код товара.
Так что этот Ваш довод отвергаю.
И повторюсь - при этом справочник у меня ОДИН. То есть и при вводе литража, класса продукции, страны изготовителя, валюты и так далее используется один и тот же объект. Только отображает он все время разные ветки дерева. Утверждается что это очень удобно. Если есть доводы почему это неудобно - в студию ;-)
Если про деревья не в справочниках то они тоже иногда нужны. Но конечно не в таком виде как Вы привели пример.
kaif (2003-02-01 15:08:00) [13]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 11:16:00) [14]ATR (31.01.03 10:16)
>80000 записей в справочнике - эт конечно не новость... Но вот пихать это в дерево... ??? А как юзер будет по нему прыгать...
Не понял вопроса? А по обычному справочнику он как прыгает? Во-первых, в 90% справочников открывается не от корня а от определенного узла. Скажем, если пользователь хочет увидеть справочник цветов то я ему и открываю с узла "Цвета".
Во вторых, если, допустим, ветка и впрямь ветвистая, то есть волшебное окошко в которой юзер вводит примерно что он ищет, есть процедурка которая в базе ищет искомое, рекурсивно поднимает спиок парентов и возвращает справочнику. Тот в свою очередь парсит список парентов и аккуратно раскрывает все до нужного "листа" или "узла". При этом "подгружая" данные если их еще нет в дереве (естественно, все дерево я сразу не гружу.) Кроме того, это же дерево становится и локальным (для клиента) справочником. То есть когда клиент поработав подкачал себе много данных то справочники просто "летают".
При организации справочника таким образом резко сокращается число пользуемых таблиц - если без дерева мне бы понадобилась не одна сотня таблиц только для справочников.
KIR (2003-01-31 18:54:00) [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;
kaif (2003-01-31 14:25:00) [16]На IB очень лихо можно писать обработку дереыьев. Я лично придумал такой подход:
1. У меня есть процедура, возвращающая данный элемент и всех предков данного элемента.
2. Есть процедура, запрашивающая для всех элементов таблицы с помощью первой процедуры всех предков и формирующая, таким образом, набор всех сочетаний предок-потомок.
3. Далее, объединяя этот набор с таблицей данных, я совершенно обычным SELECT-ом с INNER JOIN получаю любые выборки всех "дочерних и их потомков", если это нужно. И никаких рекурсий.
Однако я никогда не применяю деревья в справочниках и считаю это недальновидным временным перекладыванием своих проблем на плечи юзера. Я применяю деревья в основном в бухгалтерских счетах и других подобных однородных пространствах элементов.
Vladimir (2003-01-31 13:19:00) [17]Есть хорошая статья - деревья в SQL , лежит на
http://sdm.viptop.ru/articles/sqltrees.html- описано, как избежать рекурсии при проектировании древовидных структур. Рекомендую.
Jeer (2003-01-31 10:37:00) [18]ATR (31.01.03 10:16)
Любое представление данных имеет право на существование, если оно удобно клиенту для понимания(поиска)по классификации.
Основная проблема, с которой сталкиваются начинающие, да и не очень, разработчики - это смешивание разнородных сущностей в дереве.
В этом случае, действительно бегать глазками-ручками по дереву из 80 тыс элементов занимательно.
На мой вгляд, надо обязательно вводить понятие категорий сущностей и присваивать надлежащим узлам.
Например, категория производитель с элементом IBM может
появиться и в серверах и в винтах.
В 1С сделана попытка (абсолютно неудачная, IMHO) реализовать это через свойства.
Delirium^.Tremens (2003-01-31 10:28:00) [19]Не IB плохо работает с "деревьями", а "деревья" плохо умеют работать с IB.
Афоризм, однако :-)
ATR (2003-01-31 10:16:00) [20]80000 записей в справочнике - эт конечно не новость... Но вот пихать это в дерево... ??? А как юзер будет по нему прыгать... Он не Тарзан :) Попробуй в дереве разыщи чё нить, если оно одно как Шервудский лес...
Моё баловство с деревьями привело к возврату к табличному представлению... Так что ... не слишком увлекайтесь, парни ;)
| |
Страницы: 