iBase.ru Forum

Есть база под сервером Firebird. На клиенте используются стандартные компоненты из Borland C++ Builder 6.

Одна таблица насчитывает 30.000 записей. При полной закачке её на клиента программа по таск менеджеру забирает ~300 мегабайт памяти. Меняем столбец сортировки и снова закачиваем все записи. Размер занятой памяти временно поднимается до 600 мегабайт, потом снова прежние 300. При этом вся база весит 30 мегабайт без индексов, 45 с индексами.

Это нормально? Нельзя ли как-то уменьшить аппетит по памяти?

Можно - не качай всю таблицу на клиента.

Tonal писал(а):Можно - не качай всю таблицу на клиента. :-)

Так не я ж качаю. А другие варианты? Что-то уж очень намного объём занятой памяти больше размера данных на диске. Нельзя ли закатать IBX-ам губу?

KKomov писал(а):

Tonal писал(а):Можно - не качай всю таблицу на клиента.

Так не я ж качаю.

А хто?

KKomov писал(а): А другие варианты?

Чего варианты?

KKomov писал(а): Что-то уж очень намного объём занятой памяти больше размера данных на диске. Нельзя ли закатать IBX-ам губу?

Слово "компрессия" слышал? В смысле данных. В смысле на диске. В смысле сервером. Которые на клиенте распакованы. Малость подзакатать IBX-ам губу можно. Например, пересмотреть модель управления памятью. Но проще таки тянуть на клиента только то, что нужно, а не всё подряд, всё равно рано или поздно треснет любая память. Или, если таки нужно прокачать через клиента одноразово всё, делать это однонаправленно, без возможности скроллирвания взад, чтоб он отпускал уже просмотренное. Проперть UniDirectional.

KKomov писал(а):

Tonal писал(а):Можно - не качай всю таблицу на клиента.

Так не я ж качаю. А другие варианты? Что-то уж очень намного объём занятой памяти больше размера данных на диске. Нельзя ли закатать IBX-ам губу?

Тебе действительно все 30000 записей нужно на клиенте одновременно?
Что ты с ними делаешь-то?
Вот умеришь ты аппетиты IBX к памяти, пусть даже она станит раза в 2 меньше чем на диске (компрессия в памяти), а количество данных вырастит на 2-3 порядка, и что будешь делать?

Читай однако про SQL, select и where.

Таблицу в 30000 записей выкачивает на клиента оператор, привычный работать с DBF. К сожалению, это пока единственная большая таблица в базе, к тому же рид-онли и часто используемая, поэтому для заказчика как бельмо на глазу. Мне интересно нащупать способ сделать работу с ней полегче. Данные в ней - текст, и размер их на диске не настолько велик. Отчего же такой перебор памяти?

Может отказаться от длинных варчаров? Сейчас многие поля заданы как длинная строка VARCHAR(2000), неужели придётся урезать осетра? Вот хохма, если IBX отводит память сразу под все символы с запасом.

Или поможет ClientDataSet? Выкачать разок и не перечитывать. Интересно, переедает ли он память.

Может быть у IBQuery есть какие-то настройки, через которые можно подкрутить кеширование.

Неужели придётся устроить такое уродство - незаметно патчить запрос и подставлять туда FIRST/SKIP? Не хотелось бы.

Можно и на клиента вытянуть - я как-то вполне успешно использовал для этого TMemTableEh из EhLib-а.
Сортировка на таких объёмах будет летать.

Только задумайся, а что будет, когда размер этой табличы станет в 10-100 раз больше? А если не только её размер, но и ещё нескольких?
Твоя в память перестанет влезать.

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