Форум: "Основная";
Текущий архив: 2002.10.07;
Скачать: [xml.tar.bz2];
ВнизБольшие объёмы данных тормозят клиента. Найти похожие ветки
← →
Zemal (2002-09-26 13:08) [0]Может кто-нибудь посоветовать как найти наилучший выход из сложившейся ситуации? Может кто знает как правильно организовать?
Ситуация:
Есть сервер Оракла и две таблицы (связанные). Таблицы хорошо проиндексированы и запрос на объединение этих таблиц проходит шементом (первые 100 записей объединяются за 0.04 сек). В главной таблице более 350 тыс. записей и около 10 полей небольшого размера, в подченённой таблице более милиона записей и 4 поля (короче, накладные и их спецификации). В общем Ораклы возвращают запрос шементом, а на клиенте происходит полная фигня - моя прога съедает всю оперативку (более 100 мегов) и продолжает кушать и кушать... в общем проблема с отображением информации. Для отображения использую компоненты из Девелоппер Икспресс (Developer Xpress), а именно MasterView. Этот "мастер просмотра", конечно жрёт оперативку (для собственной внутренней индексации набора данных), но я думаю, что не только в нём дело... :( Для доступа к серверу Оракл использую компоненты ODAC.
Вот вопрос: Как сделать Fiching по данным, так сказать порционное подкачивание, по мере прокручивания компонента, осуществляющего визуализацию набора данных (dxMasterView или подобного грида)?
Тоесть набо сделать постепенное подкачивание некоторого набора данных к уже существующему набору данных.
Фиг знает что делать... Думал запустить поток, который будет получать кусок набора данных, но как довалить данные к уже существующему набору? Вот где загвоздка... и проблема с определением нужного куска из набора данных.
Ещё проблема в том, что если пользоваться первичным ключём для выборки следующей порции, то при сортировке данных пользователем по другому полю (внутренняя сортировка в dxMasterView) получится каша... вот и ещё вопрос интересный: как избежать каши и несогласованности данных. Ума не приложу как это реализованно в томже SQL Navigatore? Там довольно быстро идёт "фич" по любому запросу и его ещё можно отменить!!! Конечно понятно, что там организован поток, который делает этот "фич" и результаты возвращает в окно программы. В общем я запутался... и примеров не нашол с решением подобных проблем. Помогите, кто может. Подкиньте хоть мыслишку в "усной" форме, на счёт реализации я сам смогу решить праблы. Вся фишка в том, что муслишки, как правильно реализовать это, у меня не возникает... самой концепции не высматривается... Заранее спасибо за ответы.
← →
Zemal (2002-09-26 13:39) [1]Мдаааа... молчёк... никто, видимо, с подобными проблемами не сталкивался... :(
← →
KSergey (2002-09-26 15:47) [2]никто просто таких проблем себе не создавал...
Т.е. надо просто не выкидывать на клиента столько записей... Спросите у него например с какого по какой период или там с какого по какой номер (ну главный по идее реквизит).
Если скажет, чо надо все - сам виноват.
← →
Alex_Y (2002-09-26 16:10) [3]А может использовать GridMode в dxDBGrid?
← →
stikriz (2002-09-26 22:05) [4]Привет.
Пациент, Вам сюда :-) У меня такие же проблеммы были, но я написал потомка от TDataSet, который хранит данные в TStream, а он, конечно, TFileStream. И стало жить легче, но тебе придется дописать кое-что для Oracle, т.к. там для InterBase. Там есть Fecher - его нужно отнаследовать и добавить что надо, чтобы фечить от Oracle.
http://stikriz.narod.ru/developers.htm
Николай.
← →
kronprince (2002-09-27 10:02) [5]Леша рад что ты выздоровел :)
Действительно зачем кидать настолько большие объемы данных на клиента
У мя объемы намного меньше но тем не менее на сервере приложений стоит ограничение на количество записей, если больше 1000 то это уже тормоза на любой машине/сетке
Просто более мелкая разбивка с новым SELECTом
← →
KSergey (2002-09-27 10:07) [6]Не знаю правда как на счет оракла (я не противопоставляю! я просто не зню как там оно обстоит, дело это), MS SQL поддерживает серверные курсоры - ну там не все так чтобы просто (в смысле гладко и однозначно решает задачи), но на предмет открыть много записей и ходить по ним - очень помогает. Т.е. фактически на клиента действительно тянутся только отображаемые записи. Плюсы: открывается набор очень быстро (нет перекачки по сети всего набора). Минусы: бОльшая нагрузка на сервер (но меньшая на клиента), более медленное перемещение между записями (впрочем, когда человек ходит туда/сюда - это не очень критично, ну разве что ему хочется отмотать много страниц вверх/вниз..., но... (см. далее))
А вообще-то это все выкатывается в грид или прога сама эти записи автоматом отлопачивает? Если в грид - то позвольте спросить: а как среди такого кол-ва записей что-то можно увидеть?! Или есть поиск? Так может в этом поиске и задействовать сервер?
← →
NeyroSpace (2002-09-27 10:22) [7]А представления для этих целей не подойдут?
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2002.10.07;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.009 c