Быстрый способ заполнения массива данными из Query

← →
Fedia © (2004-10-19 05:43) [0]

Всем доброго времени суток.
У меня вот какой вопрос.

Есть в наличии:
Query1: TZMySqlQuery; Unload_h = record date: TDate; id_ves: integer; id_ves_unload: integer; conosament: string; id_own_unload: integer; own_unload, ves_unload: string; end; ArUnloadU: array of Unload_h; ClearQuery(Query1); //очистка от данных предыдущего запроса Query1.Sql.Add("Select date, id_ves, id_ves_unload, ves_unload, conosament, id_own_unload, own_unload from unload_h"); OpenDB(Query1); //Query1.Open, Query1.First и др. SetLength(ArUnloadU, Query1.RecordCount); //заполнение массива данными из Query1 for i:=0 to Length(ArUnloadU)-1 do begin ArUnloadU[i].id_ves:=Query1.fieldByName("id_ves").AsInteger; ArUnloadU[i].id_own_unload:=Query1.fieldByName("id_own_unload").AsInteger; ArUnloadU[i].id_ves_unload:=Query1.fieldByName("id_ves_unload").AsInteger; ArUnloadU[i].date:=Query1.fieldByName("date").AsDateTime; ArUnloadU[i].ves_unload:=Query1.fieldByName("ves_unload").AsString; ArUnloadU[i].own_unload:=Query1.fieldByName("own_unload").AsString; ArUnloadU[i].conosament:=Query1.fieldByName("conosament").AsString; Query1.Next; end; Непосредственно вопрос: имеется ли более быстрый способ заполнить массив ArUnloadU ? PS Использование Query1.Fields вместо Query1.fieldByName предлагать нет нужды.

← →
Ильш (2004-10-19 06:28) [1]

а зачем загонять данные в массив???? кто этому научил? и зачем это надо?

← →
Fedia © (2004-10-19 06:39) [2]

To Ильш (19.10.04 06:28) [1]
Сравни скорость работы с Query и с массивом данных и получишь ответ.
И огромная просьба: если нечего сказать по существу вопроса, то лучше ничего не писать.

← →
ЮЮ © (2004-10-19 06:52) [3]

А ты сначала закачай всю выборку на клиента, а потом сравнивай скорости. В твоем цикле эта закачка и производится.
З.Ы. И сколько записей предполагает возвращать твой запрос?

← →
Deniz © (2004-10-19 06:53) [4]

> Fedia © (19.10.04 06:39) [2]
Сначала не хотел писать, но ...
По существу.
Врядли другой способ увеличит скорось на много, так что пользуйся этим.
Не по существу.
> Сравни скорость работы с Query и с массивом данных и получишь ответ.
И сколько процентов ты выиграешь? Сколько возможностей потеряешь? Индексы свои сделаешь в массиве? Сколько времени уйдет на загон в массив + обработка одной записи? А хватит ли памяти для Select ... from unload_h замечу, что where там нет и обрабатываются все записи?
Зачем изобретать велосипед?

← →
Ильш (2004-10-19 07:06) [5]

во во во !! на счет памяти - это верно-с...
уж больно похожа эта любовь к массивам к вредным поползновениям Clippera. Видел я такие программы. А потом их пришлось переписывать потому что массивы в память не лезли :(
Никакой экономии не видно на первый взгляд. И даже если ты ее реально получил, то скорее всего с Query не так работал... :(((
а сортировать, а фильтровать как будешь массивы??? не запаришься???
ну что? по существу????

← →
Fedia © (2004-10-19 07:40) [6]

To ЮЮ © (19.10.04 06:52) [3]
>З.Ы. И сколько записей предполагает возвращать твой запрос?
на данный момент 778112 и количество довольно быстро возрастает.
>А ты сначала закачай всю выборку на клиента
не совсем Вас понял. Разве после выполнения Query.Open вся выборка не закачивается на клиента.

To Deniz © (19.10.04 06:53) [4]
>Врядли другой способ увеличит скорось на много, так что пользуйся этим.
Именно из-за надежды, что другой способ может увеличит скорость, ну хотя бы процентов на 20-30 я задал этот вопрос. У меня в последнее время непреодолимое желание все оптимизировать :)

>И сколько процентов ты выиграешь?
решение о переходе на использование массивов данных было принято еще два гола назад, поэтому точных процентов не приведу, могу сказать только, что увеличение скорости было в разы. А после изменений, которые вношу сейчас, думаю, что скорость еще заметно возрастет.
Сейчас я попытаюсь объяснить причину переноса данных в массив. При анализе информации из этой таблицы и имеющих к ней отношение таблиц, есть необходимость получать небольшие куски информации из таблицы unload_h. Если получать их через уточняющие запросы в БД, то это сотни тысяч дополнительных запросов. При работе нескольких клиентов эти запросы существенно подвешивают БД. Поэтому и было принято решение и переносе дынных в массив, и как следствие, переносе нагрузки по поиску информации на машину пользователя. О результате я уже написал.

>А хватит ли памяти для Select ... from unload_h
Памяти хватает .

← →
Fedia © (2004-10-19 07:42) [7]

Ильш (19.10.04 07:06) [5]
> по существу????
нет

← →
Ильш (2004-10-19 07:52) [8]

> имеется ли более быстрый способ заполнить массив ArUnloadU
> ?

тогда другого способа нет в общем то...
кстати - сколько времени занимает перегон в массив?

← →
Fedia © (2004-10-19 08:10) [9]

Ильш (19.10.04 07:52) [8]
>кстати - сколько времени занимает перегон в массив?
около 7-ми секунд, но у меня ПК в несколько раз мощнее, чем у пользователей, а работать с программой приходится им (масло маслинное :)).

>тогда другого способа нет в общем то...
может быть... Но подождем еще мастеров...

← →
Ильш (2004-10-19 08:23) [10]

778112 записей на клиента - вот что вызывает сомнения
разве нельзя сразу отсекать как нить?
столько записей смысла нет тянуть...
по дате может фильстровать или еще как
where пользуй

> Разве после выполнения Query.Open вся выборка не закачивается
> на клиента.

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

← →
Наталия © (2004-10-19 08:31) [11]

У меня ещё вызывает некоторое непонимание вот эта фраза:
"При анализе информации из этой таблицы и имеющих к ней отношение таблиц, есть необходимость получать небольшие куски информации из таблицы unload_h. Если получать их через уточняющие запросы в БД, то это сотни тысяч дополнительных запросов"
Если анализ производится на клиенте, то как один пользователь может породить "сотни тысяч уточняющих запросов"?
Сомневаюсь я...

← →
Fedia © (2004-10-19 08:40) [12]

Ильш (19.10.04 08:23) [10]
открою тебе страшную тайну :) Там есть "where date between ". В примере я упростил, так как это не относится к сущности вопроса (уже не могу это писать без смеха :))

>по дате может фильстровать или еще как
у меня есть процедура сортировки, выдранная из TStringList, которая довольно легко с этим справляется на машине пользователя.

>от фетчинга зависит кстати :)
можно спросить, что есть "фетчинг"

Наталия © (19.10.04 08:31) [11]
Сомневаюсь я.. Приезжайте, я при Вас установлю счетчик и проверим, на чьей стороне правда. Иначе как это можно доказать :)

← →
sniknik © (2004-10-19 08:51) [13]

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

после открытия запроса вызвать у него метод fetchall, либо last (если у компонента нет этого метода), а вот после этого сравнивать с массивом. (поиск на вхождение чеголибо, по индексу и без него, к примеру, ресортинг для изменения порядка отображения, фильтр...)

> Сомневаюсь я.. Приезжайте, я при Вас установлю счетчик и проверим, на чьей стороне правда. Иначе как это можно доказать :)
не сумлевайся, приводи метод тестирования, код, цифры. от тогда будет видно.

← →
Ильш (2004-10-19 08:53) [14]

> так как это не относится к сущности вопроса

да не относится... просто тебе пытаются объяснить неверность твоего подхода в принципе, а ты за него цепляешься...
нравится делай! :)))

> можно спросить, что есть "фетчинг"

то и есть :)))) (уже не могу это писать без смеха :))
что записи на клиента обычно не вытягиваются все!
по мере продвижения по НД подгружаются обычно... запрос выполняется скажем 10 мсек, а с полным фетчингом может занять и 10 сек.

> "сотни тысяч уточняющих запросов"

вот про это я понять не могу - как клиент генерит такое кол-во запросов?

> в последнее время непреодолимое желание все оптимизировать
> :)

так вот и советуют люди как оптимизировать!!! а ты все про массивы
суть не в них...
всем интересно где живут люди которые могут просмотреть столько записей и сделать сотни тысяч уточняющих запросов :))))

← →
Наталия © (2004-10-19 08:55) [15]

Если пользователь делает 5 запросов в секунду, абсолютно не интересуясь результатами предыдущего запроса, и так все 8 часов - то да, поверю. Но что ж это они такое делают? :))

← →
Fedia © (2004-10-19 09:09) [16]

To Наталия ©.
Я сейчас сам пытаюсь прикинуть, не переборщил ли я (ненавижу врать).
Предположим, что анализ идет только по данным за 2004 год (137860) записей. У каждой записи есть своя пара, которую необходимо найти по довольно сложному алгоритму. Пытаемся найти ее в первый раз (при этом анализируется информация, в том числе из других таблиц) - это один запрос. Если запись не удовлетворила сложному условию, то рамки поиска сильно раздвигаем - еще запрос. И так несколько раз, почти для каждой записи. Запросов на самом деле раньше было очень много. Если сразу выбирать информацию по максимально расширенным рамкам, то количество запросов уменьшается, но объемы запрашиваемой информации увеличиваются. В общем, думаю, что я не соврал.
Само собой всех нюансов я Вам здесь не опишу.

Наталия © (19.10.04 08:55) [15]
Вы думаете, что они для каждого запроса нажимают кнопку, да мы бы мышки замучились менять :)
>не интересуясь результатами предыдущего
Все результаты выводятся в итоговых выходных файлах Excel

← →
Nikolay M. © (2004-10-19 09:20) [17]

> Fedia © (19.10.04 09:09) [16]

Судя по сказанному, ошибка в ДНК и оптимизировать нужно не 10 строчек на клиенте, а структуру базы и логику хранения данных в ней. Ты для каждой из 100 000(!) записей делаешь кучу кривых запросов, а оптимизируешь почему-то скорость фетча этих 100 000 записей на клиента. Имхо, что-то не так в консерватории...

← →
ЮЮ © (2004-10-19 09:25) [18]

>У каждой записи есть своя пара, которую необходимо найти по довольно сложному алгоритму. Пытаемся найти ее в первый раз (при этом анализируется информация, в том числе из других таблиц) - это один запрос. Если запись не удовлетворила сложному условию, то рамки поиска сильно раздвигаем - еще запрос.

1)Надо было использовать реляционную модель, а не алгоритмическую
2) можно было бы порекомендовать порождать запросы не для каждой записи, а для всей таблицы сразу, но, в силу 1), это, скорей всего, невозможно

← →
Ильш (2004-10-19 09:32) [19]

Щас еще придут мастера и вообще порвут Fedю за такое проектирование :))))
в любой задаче связанной с БД оптимизирование заключается:
1. в работе со структурой данных
2. оптимизации запросов, индексов, хп и прочего
3. клиент нужен то ка для отображения результата

← →
Johnmen © (2004-10-19 09:39) [20]

Зачем мастерам рвать Федю ? Его юзеры порвут...:)))

← →
Fedia © (2004-10-19 09:49) [21]

Ильш (19.10.04 08:53) [14]
>нравится делай! :)))
Нравиться, не нравиться, главное скорость :)
А если серьезно, но пока не вижу способа оптимизации с использованием дополнительных запросов.

>вот про это я понять не могу - как клиент генерит такое кол-во запросов?
см. [16]

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

>всем интересно где живут люди которые могут просмотреть столько записей и сделать сотни тысяч уточняющих запросов :))))
Таких людей нет. Путин. :) Как я уже писал выше, пользователь на выходе получает файл Excel, в котором разумеется не вся информация, упрощенно можно сказать что там информация по записям, для которых так и не найдена пара, или найдена, но при сильно расширенных рамках поиска. Так что пользователей здесь никто не мучает :)

Отдохни парень. Клиент - это в общем случае, приложение, формирующее и отсылающее запросы в базу данных. Что он дальше с ней делает - это не суть...

← →
Fedia © (2004-10-19 09:53) [22]

Johnmen © (19.10.04 09:39) [20]
Это Вы по собственному опыту :)

← →
Johnmen © (2004-10-19 09:57) [23]

Fedia © (19.10.04 09:53) [22]
Нет, по чужому :)

← →
Fedia © (2004-10-19 10:03) [24]

Johnmen © (19.10.04 09:57) [23]
Значит Вам, как и мне сопутствует удача, и слава Богу :)

← →
ЮЮ © (2004-10-19 10:05) [25]

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

Может уточнишь и нам сообща удастся построить запрос, который вернет эту жалкую сотню записей из 778112 ?

← →
Fedia © (2004-10-19 10:11) [26]

Nikolay M. © (19.10.04 09:20) [17]
Структуру базы данных разрабатывали в Москве, по заказу Гос. коммитета по рыболовству. Ее структура может быть и не на 100% оптимальна, но даже я не жалуюсь.
Другое дело, это то, какие задачи перед нами ставят. Иногда их приходится решать не самыми очевидными и простыми путями.
>Ты для каждой из 100 000(!) записей делаешь кучу кривых запросов
Если внимательно прочитать предыдущие постинги, то уже два года, как не делаю

> а оптимизируешь почему-то скорость фетча этих 100 000 записей на клиента
Этот вопрос я задал чисто из интереса узнать, что посоветуют люди. Свои соображения на этот счет у меня есть.

PS не пытайтесь поставить диагноз несуществующей болезни. Видать вопрос с массивами у вас на форуме очень больной.

← →
ЮЮ © (2004-10-19 10:20) [27]

>Видать вопрос с массивами у вас на форуме очень больной.

Убери заполнение массивов и оставь только Query1.Next. Что быстрее cтало? :)

← →
Vlad © (2004-10-19 10:23) [28]

> Fedia © (19.10.04 10:11) [26]

Ты бы уточнил структурку таблиц и что тебе в итоге получить надо. А то и вправду диагноз поставят.

>Убери заполнение массивов и оставь только Query1.Next

А теперь убери Query1.Next и поставь
ArUnloadU[i].id_ves:= IntToStr(i);
...

Теперь у тебя есть информация, что именно нуждается в оптимизвциии

Vlad © (19.10.04 10:23) [28]
диагноз это не страшно. Безразличие - вот самое страшное :)
По поводу структуры либо чуть позже, либо завтра. У нас тут знаете ли уже темнеет, а еще домой нужно добраться, выспаться и опять на работу :)

> asp © (19.10.04 10:25) [29]

> Рассматривал как альтернативу массиву класс TList?

а TList это тот же массив. Только память выделяется порциями, что в данном случае (наверное) только замедлит работу.

> Структуру базы данных разрабатывали в Москве, по заказу
> Гос. коммитета по рыболовству

Оооо. В Москве... Это реально круто!
Знаю я, как эти базы разрабатывают. Выделяется грант на несколько тысяч убиенных енотов, которые распределяются между приближенными, на 500 баксов берется студент технического вуза, который с радостью клепает "нечто", с чем потом таким как ты приходится мучиться.

Не вдаваясь в дигноз могу предложить попробовать ClientDataSet - фетчишь в него все данные и ищешь-сортируешь в нем что угодно.

Vlad © (19.10.04 10:34) [32]>
Думаю, наверняка замедлит при инициализации, по причине как раз порционного выделения памяти. Но, возможно, при дальнейшей работе будет легче.

>Fedia © (19.10.04 10:35) [33]

т.е. 0.3 секунды на получение и "просмотр" 778112 записей. А ты говорил, что Query отдыхает, когда рядом есть массивы.

> Johnmen © (19.10.04 10:42) [37]

Про студентов-то? Не то слово :-(
Какая разница, какой будет результат, если откаты уже сделаны, деньги выделены и распределены. Создать ИМБУРДЕ (ИМитацияБУРнойДЕятельности), написать отчеты о проделанной работе, студенту что-то наклепать - все довольны :(

Nikolay M. © (19.10.04 10:37) [34]
Да я понимаю, что " В Москве" не сильный аргумент, но БД получилась вполне адекватной большинству решаемых задач (это далеко не только мое мнение). Может быть разрабатывали ее и студенты, но принимали ее и корректировали уже специалисты.

ЮЮ © (19.10.04 10:41) [36]
организуйте цикл по любому массиву, длиной 778112, не делая ничего внутри цикла и сравните с 0.3 секундами.

Всем до завтра.

Быстрый способ заполнения массива данными из Query Найти похожие ветки