Комфортно работать с большими treelistview

← →
12 © (2010-11-10 12:10) [0]

в программе должно быть 10 деревьев, число нодов, соответственно, штук
310002
254951
690114
413616
173786
591637
395267
657713
408273
571554
построил минимальное дерево (173786 штук) и поскучнело как то сразу

а еще учесть, что программа будет на одном компьютере работать, куда удаленно будут заходить в среднем до 5 юзеров одновременно..

Хорошо, дерево можно строить по мере раскрытия ветки.
Но первый раз требуется именно все ветки открывать - это потом юзеры сами распихают ноды по другим нодам

Но, опять же, пусть даже 20% нодов-веток, все равно останутся корневыми..

что мне можно посоветовать, кроме как не спамить :)

← →
clickmaker © (2010-11-10 12:17) [1]

virtualmode?

← →
Sergey13 © (2010-11-10 12:21) [2]

Откуда дровишки, т.е. деревья? 8-)
ИМХО надо как то продумывать интерфейс и логику работы с данными, чтобы уйти от таких сумашедших (для деревьев) цифирей.
Без описания задачи что-то более конкретное советовать трудно.

← →
12 © (2010-11-10 12:38) [3]

> ИМХО надо как то продумывать интерфейс и логику работы с
> данными

надо..
второй день пошел - ничего

> Откуда дровишки

клиенты шараги, по отделениям, по России
т.е. фирма, допустим, может иметь несколько дочерних, вот они ее ветки будут.
у тех, соответственно тоже.
или просто одна фирма несколько раз зарегистрирована - их, логически, тоже как ветки для ветки.имя=любая_из_них надо покзывать

← →
12 © (2010-11-10 12:44) [4]

> virtualmode?

не понял мысль

← →
Медвежонок Пятачок © (2010-11-10 12:47) [5]

http://www.soft-gems.net/index.php?option=com_content&task=view&id=12&Itemid=33

Хоть мульон узлов.
Стресс тест демо показывает на атлоне 650 мгц 256 мб рам ~ 850ms на загрузку

← →
Jeer © (2010-11-10 12:52) [6]

В свое время тоже встала такая задача.
Решил изменением способа построения дерева: от рекурсивного через поиск дочек к линейному, используя отдельное поле Level, соответствующее уровню текущей node.
Скорость выросла более чем на порядок.

← →
Медвежонок Пятачок © (2010-11-10 12:56) [7]

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

← →
12 © (2010-11-10 13:49) [8]

> Медвежонок Пятачок © (10.11.10 12:56) [7]
>
> рекурсивная загрузка из бд конечно тормозит

не, именно она нужна
откуда ж еще по поллимона строк взять

← →
Jeer © (2010-11-10 13:52) [9]

> не, именно она нужна

Я ж говорю - она не нужна :)

← →
12 © (2010-11-10 13:57) [10]

> Я ж говорю - она не нужна :)

я понял :)

все равно долго.
smrtqry1.Open; tv1.Items.BeginUpdate; while not(smrtqry1.Eof) do begin tv1.Items.AddChild(nil,smrtqry1.FieldList[0].AsString); smrtqry1.Next; end; tv1.Items.EndUpdate;
просто, ничего не вычисляя, и уже неприемлимо.

Вот думаю, может, гридом, с кол-вом пробелов перед именем, соответственно уровню вложения..

← →
RWolf © (2010-11-10 14:06) [11]

зачем всё-то загружать? юзер больше пары десятков одновременно всё равно не видит. листнули окно — подгрузили следующую порцию, профит.

← →
12 © (2010-11-10 14:16) [12]

> зачем всё-то загружать?
а если листанули до конца?
а если из начала node drag&dropом понесли в конец, а потом полученную ветку в середину?
в начале эксплуатации так и будет..

Вот думаю, может, гридом с кол-вом пробелов перед именем, соответственно уровню вложения
DAO очень хорошо работает, со стандартным dbGrid, как-то fetchит именно порциями так, что тормозов особо и не видать

← →
RWolf © (2010-11-10 14:21) [13]

> а если листанули до конца?а если из начала node drag&dropом
> понесли в конец, а потом полученную ветку в середину?

не вижу ничего страшного. листанули до конца — с конца и подгрузим те же два десятка строчек.
а тянуть драг-н-дропом через стотыщ строк ни один юзер не осилит.

← →
clickmaker © (2010-11-10 14:25) [14]

> а если из начала node drag&dropом понесли в конец, а потом
> полученную ветку в середину?

это при таком количестве нодов, как в [0]?
а юзер не охренеет?

← →
Медвежонок Пятачок © (2010-11-10 14:28) [15]

Вот думаю, может, гридом

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

← →
12 © (2010-11-10 14:40) [16]

> это при таком количестве нодов, как в [0]?
> а юзер не охренеет?

придется не охреневать. А чего делать..
Вообще-то, может какой-нить контейнер сделать, типа, кинул туда, он там, как в буфере обмена, домотал до нужного места и из буфера его туда..

> само дерево после этого не тормозит.

дык, само дерево TTreeView; и не тормозит после построения. Вернее, приемлемо тормозит.

построение списка занимает в 50 раз больше времени, чем запрос.
с гридом, вообщем, самое то. FethRows = 1000 и почти летает. Почти :)
Как он это делает.. надо бы разобраться, конечно.

← →
clickmaker © (2010-11-10 14:43) [17]

> придется не охреневать. А чего делать..

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

← →
Медвежонок Пятачок © (2010-11-10 14:46) [18]

построение списка занимает в 50 раз больше времени, чем запрос.

Ну и при чем здесь тогда вообще тривью в вопросе?

← →
Медвежонок Пятачок © (2010-11-10 14:50) [19]

Как он это делает.. надо бы разобраться, конечно.

Он тупо фетчит данные ни о чем не заботясь.
А ты либо рекурсивно посылаешь множество запросов, либо используешь один линейный датасет, и время тратится на поиски парентов плюс создание самих узлов.

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

сразу увидишь что именно тормозит.

← →
Sergey13 © (2010-11-10 14:55) [20]

> [3] 12 © (10.11.10 12:38)
> клиенты шараги, по отделениям, по России
> т.е. фирма, допустим, может иметь несколько дочерних, вот
> они ее ветки будут.
> у тех, соответственно тоже.
> или просто одна фирма несколько раз зарегистрирована - их,
> логически, тоже как ветки для ветки.имя=любая_из_них надо
> покзывать

1 вариант. Судя по вышепроцитированному, структура должна быть похожа на проводник и файловую систему, когда п 90% данных лежат на последнем уровне. Если их вывести из "дерева" и класть рядом, в гриде например, то нагрузка на дерево снизится.
2 вариант. Разбить одно дерево на несколько по следующей схеме. Сначала строится "супер дерево" например с областями страны (ну или как там у тебя), на конце которого, вместо "листиков" растут обособленные деревья, которые описывают какую то обособленную группу, типа твоих дочерних фирм.

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

ЗЫ: сумбурно как то получилось, сори.

← →
12 © (2010-11-10 14:57) [21]

> сделай простое исследование.
> возьми тот же самый линейный датасет

дык я про что

c1 := GetTickCount;
smrtqry1.Open;
c2 := GetTickCount;
// tv1.Items.BeginUpdate;
// while not(smrtqry1.Eof) do
// begin
// tv1.Items.AddChild(nil,smrtqry1.FieldList[0].AsString);
// smrtqry1.Next;
// end;
// tv1.Items.EndUpdate;
c3 := GetTickCount;
FmtStr(s, "%d тиков запрос, %d тиков построение, %d тиков всего",[c2-c1, c3-c2, c3 - c1]);
mmo1.Lines.Add(s);

и в 50 построение дольше запроса.

> > придется не охреневать. А чего делать..
> и неужели никак не разгруппировать такую туеву хучу данных?

Как?
1. по алфавиту, на каждую букву, если на отдельной вкладке
2. или просто запретить весь список строить. Пусть введут хотя бы 2-3 буквы, для начала.

← →
Медвежонок Пятачок © (2010-11-10 15:02) [22]

дык я про что

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

а сколько времени занимает непосредственно сам while not eof do next;?
без возни с деревом?

← →
12 © (2010-11-10 15:03) [23]

Еще раз.
Наверное не понятно и неточно написал первый раз.
Наследие такое - Большая плоская таблица.
Надо перегнать в структуру-дерево.
Нет пока признаков никаких, кроме того, что каждый менеджер знает своих клиентов. (правда, в 90% случаев название схожие, глаз определит)

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

правильно!
но!, кто решит кто куда относится, кроме менеджера. Вот им и надо сделать инструмент, чтоб они сами сформировали такой список.

← →
clickmaker © (2010-11-10 15:04) [24]

> 2. или просто запретить весь список строить. Пусть введут
> хотя бы 2-3 буквы, для начала.

как вариант - да, автокомплит. Причем, данные подтягивать с сервака (из базы) в момент запроса, а не все сразу фетчить на клиент.

Не совсем понятно, зачем юзеру одномоментно весь этот лес видеть одним взором?
Ведь он же в текущий момент с одной фирмой работает, нет?

← →
RWolf © (2010-11-10 15:08) [25]

согласен с [22] — VirtualTreeView решит все проблемы.
главное — выбрать правильный контейнер для хранения дерева в памяти.

← →
Sergey13 © (2010-11-10 15:09) [26]

> [23] 12 © (10.11.10 15:03)
> но!, кто решит кто куда относится, кроме менеджера. Вот
> им и надо сделать инструмент, чтоб они сами сформировали
> такой список.

Сейчас менеджеры как то работают с этим? Не со всей же "Большой плоская таблица" в одном гриде?

> а сколько времени занимает непосредственно сам while not
> eof do next;?
> без возни с деревом?

ну, конечно, и даже на пару порядков меньше, если так
while not(smrtqry1.Eof) do
begin
//tv1.Items.AddChild(nil,smrtqry1.FieldList[0].AsString);
smrtqry1.Next;
end;

контейнер там нужен будет не для дерева, а для узла дерева.
само дерево - оно само по себе контейнер дерева.

ну, конечно, и даже на пару порядков меньше, если так

То есть тормозит уже сам тривью при его наполнении. независимо от того, насколько быстро поставляются данные для его загрузки.

> Сейчас менеджеры как то работают с этим? Не со всей же "Большой
> плоская таблица" в одном гриде?

с большой таблицей, ибо бардак :)
только накладывая фильтр по названию клиента и региону
where name like :L
and region = :R

> VirtualTreeView

Убедили, сейчас гляну ..

> 12 © (10.11.10 15:20) [30]
>
>
> > Сейчас менеджеры как то работают с этим? Не со всей же
> "Большой
> > плоская таблица" в одном гриде?
>
> с большой таблицей, ибо бардак :)

Тогда присоединяюсь к мнению или уточняю его, что неверна постановка работы пользователей + не ограничен интерфейс.

> Наследие такое - Большая плоская таблица.
> Надо перегнать в структуру-дерево.

т.е. раскидать филиалы по фирмам?
ну можно завести два списка, в каждом из которых эта плоская таблица, отсортированная по именам, и перетаскивать из левого в правый на элемент-родитель, убирая из левого.
списки снабдить фильтром для быстрого поиска или урезания, либо разбить по алфавиту на закладки

> [30] 12 © (10.11.10 15:20)
> с большой таблицей, ибо бардак :)
> только накладывая фильтр по названию клиента и региону

ИМХО если им в это рабочее место добавить простановку нужных параметров и одновременно предложить им новый интерфейс, использующий эти параметры, то в скором времени сами все разнесут.

Это практическая постановка для OLAP-систем, чем я занимаюсь крайние 6 лет.
Создаются таблицы-измерений ( справочники ) по которым и нарезается конкретная плоская ( двумерная ) таблица из гиперкуба.
Обычно достаточно размерностей 7 плюс-минус 2..3

К примеру, для социо-экономических показателей, как показала практика, достаточно следующих таблиц-измерений ("деревянных"):
- регион;
- источник информации;
- ОКВЕД;
- период;
- способ учета;
- системы показателей;
- показатели;

VirtualTreeView - вещь!
Все, спасибо всем! И особенно, МП :)

> т.е. раскидать филиалы по фирмам?

нет, они, в принципе, раскиданы.
Раскидать по дочерним/подчиненным надо.

Дерево всех в филиале,
с "карманом" где-то слева/справа от дерева, самое то.

> ИМХО если им в это рабочее место добавить простановку нужных
> параметров и одновременно предложить им новый интерфейс,
> использующий эти параметры, то в скором времени сами все
> разнесут.

тоже об этом говорил, пусть разметят, потом одним запросом и сделаем дерево.
Но все филиалы используют "свой софт" :) для этого.
Это всем разослать переходную приблуду, нормальную.

Надо сразу нормальную. с возможностью перемещать ноды.
Потом фирмы сольются/разделятся - функционал уже есть. Мышой перетащат и делов то..

VirtualTreeView - вещь!!
да он даже понятнее в методах, логичнее, имхо

> да он даже понятнее в методах, логичнее, имхо

Странно, что ты раньше внимание не обратил.
Mike Lischke надо знать в лицо :)

Комфортно работать с большими treelistview Найти похожие ветки