Объем результатов запроса

Запрос (сделанный из Си) возвращает некоторое количество строк с полем blob (запрашивается только это поле), длинна данных в котором может быть разной.
Все данные мне нужно поместить в один массив. Для этого неплохо бы знать общую длинну всех данных до того как я начну их копировать в массив. Как это сделать с меньшими потерями времени и памяти?

mihail_13,

-- преселект можно сделать с OCTET_LENGTH
-- заране посчитать размеры и записать в колонке
-- многие драйверы расчитывают размер записи
после вытаскивания... или нужно ДО?

javajdbc
mihail_13, -- преселект можно сделать с OCTET_LENGTH -- заране посчитать размеры и записать в колонке -- многие драйверы расчитывают размер записи после вытаскивания... или нужно ДО?

Как узнать длинну каждой строки это понятно. В конце концов ее можно узнать в Си после mysql_fetch_row().
Только мне, перед тем как говорить mysql_fetch_row(), хотелось бы знать суммарную длинну всех строк, которые возвращены. Их количество я могу посмотреть сразу после mysql_store_result() вызвав mysql_num_rows(). Чего-то похожего возвращающего размер записи я не нашел. Может плохо искал?

mihail_13,

я не в курсе конкретного драйвера.

если данные стабильные то может один раз
определить длину (записать в отдельную колонку)
а потом 100 раз быстро
вытаскивать в преселкте.

Алтернативно -- легко прикинуть среднюю длину блоба
в таблицы (из размера таблицы из инфо_схемы).
Зная количвство записей -- сделать прикидку
из среднего -- ну накинуть 20-40% чтоб нечасто
ошибатся в оценке.

javajdbc,

К сожаление длинна может колебаться от нескольких байт до сотен килобайт, а если массив куда я считываю окажется короче, данных будут неприятность.
Есть ли возможность дважды пройти по списку полученных результатов не повторяя запрос к базе?

mihail_13,
а зачем именно в массив? почему не в расширяемую структуру, например, список?

а что оперативки хватит уверены?

mihail_13
javajdbc, К сожаление длинна может колебаться от нескольких байт до сотен килобайт, а если массив куда я считываю окажется короче, данных будут неприятность. Есть ли возможность дважды пройти по списку полученных результатов не повторяя запрос к базе?

после запроса -- это как позволит драйвер, для второго
прохода данные придется закешировать... где-то...

где-то может быть
-- Ци-програма которая считала ресулт_сет в массив
-- драйвер позволит повторный проход но должен кешшировать сам
-- создать временую таблицу в СКЛ-е, записать туда результат,
потом запросить размер результат и только потом
запросить записи и временой таблицы
-- в Оракле есть WITH который построит результат
в памяти и к нему можно обрашатся несколько раз в том-же СКЛе,
типа;

with (очень долгий селект) abc
select sum(ocret_length(blob_col)) from abc
union
select blob_col from abc

типа получить размер в первой строчке.
Ну тип данных надо синхронизировать для юниона,
КАСТ или КОНВЕРТ какой-нубидь...

miksoft
mihail_13, а зачем именно в массив? почему не в расширяемую структуру, например, список? а что оперативки хватит уверены?

Я не уверен что на таблицу жестких дисков хватит, не то что оперативки...

Расширяемая структура может быть только состоящей из частей, а с ней работать медленней, чем с линейным массивом.

javajdbc,

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

mihail_13
miksoft mihail_13, а зачем именно в массив? почему не в расширяемую структуру, например, список? а что оперативки хватит уверены? Я не уверен что на таблицу жестких дисков хватит, не то что оперативки...

Тогда что вы подразумеваете под словом "массив", если он даже на жесткие диски может не влезть?

mihail_13
Расширяемая структура может быть только состоящей из частей, а с ней работать медленней, чем с линейным массивом.

Зависит от того, что вы с ней будете делать. На мой взгляд, потери, если у и будут, то будут весьма незначительны на общем фоне.