Скажите пожалуйста, как я понимаю, при работе с БД и выводе данных в TreeView, эти данные необходимо хранить в массиве или промежуточном файле? Или организация хранения данных может быть иная?

можно в массиве, можно и в файле... можно и другую органзицию использовать...

А зачем еще и отдельно хранить???    И так в БД же храняться! Или я чего-то не понимаю?

Я лично делаю специально специфические контейнеры для хранения. Просто, быстро, удобно. Потом по ним строю дерево.   

Просто хотелось бы, чтобы "из дерева" эти данные могли изменяться...



А как удобнее и БЫСТРЕЕ?

Т.е. ты считываешь данные из БД в контейнер, а потом уже строишь дерево. Верно? А зачем? Для чего такие потери скорости? Да и где "просто, быстро, удобно"??? Покажи!!!



А что мешает это делать без использования левых массивов или файлов?



Непосредственно в БД.

Насколько я понимаю, необходимо хранить id в каком-либо поле, например, в поле Дата узла дерева?

Да, примерно так. А еще лучше - используй VirtualTreeView. Возможностей значительно больше + есть надстройка над VT именно для работы с БД.

А что такое ВТВ? Это дополнительный компонент или стандартный?

Дополнительный. Почитай вот это

В зависимости от задачи! Если жизненный цикл твоих данных равен всему приложению, то как быть??? А как быть с BLOB полями? Все естественно зависит от задачи. Но большинство задач которые мне приходилось решать оптимально решались в две транзакции. Одна при старте, другая при закрытии. 
А про потери в скорости лучше не говори. Зависит от задачи. Иногда поиск по контейнеру (если организовать как хэш) на порядки быстрее будет проходить чем обход по БД.

П.с. В специфике моей работы время затраченное на открытие и закрытие транзакции неприемлемо. Приблизительно в 5 раз превышает норму.

Так что RadmiR все зависит от того что нужно тебе! А организовать можно как тебе угодно.   

Это сообщение отредактировал(а) Mephisto - 4.4.2007, 09:44

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

Согласен. Слушай, а ты это из первого поста понял что именно так и происходит?
Там написано что дерево строится.  Если с этой деревяхой нужно буит дальше всякие шаманские действа проводить, то ИМХО контейнер рулит. Особенно в случае VirtualTreeView. 

Да и вообще динамическая деревяха это сильно. 

   Не согласен...

Т.е. ты считаешь что лучше написать обертку вокруг самой деревяхи?   
Мне лично проще написать поведение для самого элемента дерева в отдельности. ИМХО верное решение. Не люблю процедурный подход к дереву!