Мастера 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 предлагать нет нужды.

ЮЮ (2004-10-19 10:41:00) [21]
>Fedia © (19.10.04 10:35) [33]

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

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

Nikolay M. (2004-10-19 10:37:00) [23]

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

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

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

Fedia (2004-10-19 10:35:00) [24]
ЮЮ © (19.10.04 10:20) [27]
без заполнения массива в 26 раз быстрее.

Vlad (2004-10-19 10:34:00) [25]

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

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

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

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

ЮЮ (2004-10-19 10:28:00) [27]
>Убери заполнение массивов и оставь только Query1.Next

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

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

asp (2004-10-19 10:25:00) [28]
Fedia © (19.10.04 05:43)>
Рассматривал как альтернативу массиву класс TList?

Vlad (2004-10-19 10:23:00) [29]

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

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

ЮЮ (2004-10-19 10:20:00) [30]
>Видать вопрос с массивами у вас на форуме очень больной.

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

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

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

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

ЮЮ (2004-10-19 10:05:00) [32]
>Пытаемся найти ее в первый раз (при этом анализируется информация, в том числе из других таблиц) - это один запрос.
>можно сказать что там информация по записям, для которых так и не найдена пара

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

Fedia (2004-10-19 10:03:00) [33]
Johnmen © (19.10.04 09:57) [23]
Значит Вам, как и мне сопутствует удача, и слава Богу :)

Johnmen (2004-10-19 09:57:00) [34]
Fedia © (19.10.04 09:53) [22]
Нет, по чужому :)

Fedia (2004-10-19 09:53:00) [35]
Johnmen © (19.10.04 09:39) [20]
Это Вы по собственному опыту :)

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

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

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

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

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

Johnmen (2004-10-19 09:39:00) [37]
Зачем мастерам рвать Федю ? Его юзеры порвут...:)))

Ильш (2004-10-19 09:32:00) [38]
Щас еще придут мастера и вообще порвут Fedю за такое проектирование :))))
в любой задаче связанной с БД оптимизирование заключается:
1. в работе со структурой данных
2. оптимизации запросов, индексов, хп и прочего
3. клиент нужен то ка для отображения результата

ЮЮ (2004-10-19 09:25:00) [39]
>У каждой записи есть своя пара, которую необходимо найти по довольно сложному алгоритму. Пытаемся найти ее в первый раз (при этом анализируется информация, в том числе из других таблиц) - это один запрос. Если запись не удовлетворила сложному условию, то рамки поиска сильно раздвигаем - еще запрос.

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

Nikolay M. (2004-10-19 09:20:00) [40]

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

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

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

Наверх

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