Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3
Fedia © (2004-10-19 05:43:00)
Всем доброго времени суток.
У меня вот какой вопрос.

Есть в наличии:
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 предлагать нет нужды.

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

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

Наталия (2004-10-19 08:55:00) [42]
Если пользователь делает 5 запросов в секунду, абсолютно не интересуясь результатами предыдущего запроса, и так все 8 часов - то да, поверю. Но что ж это они такое делают? :))

Ильш (2004-10-19 08:53:00) [43]

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

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

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

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

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

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

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

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

sniknik (2004-10-19 08:51:00) [44]
клиентский курсор - данные закачиваются на клиента в память обработка на клиенте.
серверный курсор - данные выбираются по мере необходимости (туда же на клиента), задействованы и сервери клиент. после перекачки (фетчинга) обработка на клиенте с той же скоростью.

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

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

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

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

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

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

Наталия (2004-10-19 08:31:00) [46]
У меня ещё вызывает некоторое непонимание вот эта фраза:
"При анализе информации из этой таблицы и имеющих к ней отношение таблиц, есть необходимость получать небольшие куски информации из таблицы unload_h. Если получать их через уточняющие запросы в БД, то это сотни тысяч дополнительных запросов"
Если анализ производится на клиенте, то как один пользователь может породить "сотни тысяч уточняющих запросов"?
Сомневаюсь я...

Ильш (2004-10-19 08:23:00) [47]
778112 записей на клиента - вот что вызывает сомнения
разве нельзя сразу отсекать как нить?
столько записей смысла нет тянуть...
по дате может фильстровать или еще как
where пользуй

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

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

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

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

Ильш (2004-10-19 07:52:00) [49]

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

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

Fedia (2004-10-19 07:42:00) [50]
Ильш (19.10.04 07:06) [5]
> по существу????
нет

Fedia (2004-10-19 07:40:00) [51]
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
Памяти хватает .

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

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

ЮЮ (2004-10-19 06:52:00) [54]
А ты сначала закачай всю выборку на клиента, а потом сравнивай скорости. В твоем цикле эта закачка и производится.
З.Ы. И сколько записей предполагает возвращать твой запрос?

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

Ильш (2004-10-19 06:28:00) [56]
а зачем загонять данные в массив???? кто этому научил? и зачем это надо?

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »