Швидкий спосіб заповнення масиву даними з Query
Всім доброго часу доби. У мене ось яке питання.
В наявності: 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 пропонувати немає потреби.
а навіщо заганяти дані до масиву. хто цьому навчив? і навіщо це треба?
To Ильш (19.10.04 06:28) [1] Порівняй швидкість роботи з Query і з масивом даних і отримаєш відповідь. І величезне прохання: якщо нічого сказати по суті питання, то краще нічого не писати.
А ти спочатку закачай усю вибірку на клієнта, а потім порівнюй швидкості. У твоєму циклі це закачування іВиготовляється. З.И. І скільки записів передбачає повертати твій запит?
ось ось !! на рахунок пам'яті - це правильно. Аж надто схожа ця любов до масивів до шкідливих намірів Clippera. Бачив такі програми. А потім їх довелося переписувати тому що масиви в пам'ять не лізли :( Жодної економії не видно на перший погляд. І навіть якщо ти її реально отримав, то швидше за все з Query не так працював. :((( а сортувати, а фільтрувати як будеш масиви.не запаришся.Ну що?по суті.
>І скільки відсотків ти виграєш? рішення про перехід на використання масивів даних було прийнято ще два голи тому, тому точних відсотків не наведу, можу сказати тільки, що збільшення швидкості було в рази. А після змін, які вношу зараз, гадаю, що швидкість ще помітно зросте. Зараз я спробую пояснити причину перенесення даних до масиву. При аналізі інформації з цієї таблиці та таблиць, що мають до неї відношення, є необхідність отримувати невеликі шматки інформації з таблиці unload_h. Якщо отримувати їх через уточнюючі запити до БД, це сотні тисяч додаткових запитів. Працюючи кількох клієнтів ці запити істотно підвішують БД. Тому і було прийнято рішення та перенесення динних у масив, і як наслідок, перенесення навантаження з пошуку інформації на машину користувача. Про результат я вже написав.
>А чи вистачить пам'яті для Select. from unload_h Пам'яті вистачає.
Ільш (19.10.04 7:06) [5] > по суті. ні
> чи є швидший спосіб заповнити масив ArUnloadU > ?тоді іншого способу немає взагалі то. до речі - скільки часу займає перегін у масив?
Ільш (19.10.04 07:52) [8] >до речі - скільки часу займає перегін умасив? близько 7-ми секунд, але у мене ПК в кілька разів потужніший, ніж у користувачів, а працювати з програмою доводиться їм (олія оливкова :)).
Тоді іншого способу немає в загальному то. можливо. Але зачекаємо ще майстрів.
778112 записів на клієнта - ось що викликає сумніви хіба не можна відразу відсікати як нитку? стільки записів сенсу немає тягнути. за датою може фільтрувати або ще як where користуватися> Хіба після виконання Query.Open вся вибірка не закачується > на клієнта.від фетчингу залежить до речі :) навіщо тягнути все? він тягне струму ті, що відображаються, а потім при необхідності дотягує інші.
У мене ще викликає деяке нерозуміння ось ця фраза: "При аналізі інформації з цієї таблиці і таблиць, що мають до неї відношення, є необхідність отримувати невеликі шматки інформації з таблиці unload_h. Якщо отримувати їх через уточнюючі запити в БД, то це сотні тисяч додаткових запитів" Якщо аналіз проводиться на клієнті, то як один користувач може породити "сотні тисяч уточнюючих запитів"? Сумніваюся я.
Ільш (19.10.04 8:23) [10] відкрию тобі страшну таємницю :) Там є "where date between". У прикладі я спростив, так як це не відноситься до сутності питання (вже не можу це писати без сміху :))
>за датою може фільтрувати або ще як у мене є процедура сортування, видерта з TStringList, яка досить легко з цим справляється на машині користувача.
>від фетчингу залежить до речі :) можна запитати, що є "фетчинг"
клієнтський курсор - дані закачуються на клієнта на згадку обробка на клиенте. серверный курсор - дані вибираються за необхідності (туди ж клієнта), задіяні і сервери клієнт. післяперекачування (фетчингу) обробка на клієнті з тією ж швидкістю.
після відкриття запиту викликати в нього метод fetchall, або last (якщо компонент цього методу немає), а ось після цього порівнювати з масивом. (Пошук на входження чогось, за індексом і без нього, наприклад, ресортинг для зміни порядку відображення, фільтр.)
> Сумніваюся я. Приїжджайте, я при Вас встановлю лічильник і перевіримо, на чиєму боці правда. Інакше як це можна довести :) не сумуйся, наводь метод тестування, код, цифри. тоді буде видно.
> оскільки це не відноситься до сутності питаннятак не відноситься. просто тобі намагаються пояснити зрадливість твого підходу в принципі, а ти за нього чіпляєшся. подобається роби! :)))
> можна запитати, що є "фетчинг"і є :)))) (вже не можу це писати без сміху :)) що записи на клієнта зазвичай не витягуються все! у міру просування НД підвантажуються зазвичай. запит виконується скажімо 10 мсек, а з повним фетчінг може зайняти і 10 сек.
> "сотні тисяч уточнюючих запитів"ось про це я зрозуміти не можу - як клієнт генерує таку кількість запитів?
Якщо користувач робить 5 запитів на секунду, абсолютно не цікавлячись результатами попереднього запиту, і так усі 8 годин – то так, повірю. Але що це вони таке роблять? :))
>У кожного запису є своя пара, яку необхідно знайти за досить складним алгоритмом. Намагаємося знайти її вперше (при цьому аналізується інформація, у тому числі з інших таблиць) – це один запит. Якщо запис не задовольнив складну умову, то рамки пошуку сильно розсуваємо - ще запит.
1) Потрібно було використовувати реляційну модель, а не алгоритмічну 2) можна було б порекомендуватипороджувати запити не кожної записи, а всієї таблиці відразу, але, з 1), це, швидше за все, неможливо
Щас ще прийдуть майстри і взагалі порвуть Fedю за таке проектування :)))) у будь-якій задачі пов'язаної з БД оптимізація полягає: 1. у роботі зі структурою даних 2. оптимізації запитів, індексів, хп та іншого 3. клієнт потрібен для відображення результату
Навіщо майстрам рвати Федю? Його користувачі порвуть. )))
Ільш (19.10.04 8:53) [14] подобається роби! :))) Подобається, не подобається, головне швидкість :) А якщо серйозно, але поки не бачу способу оптимізації з використанням додаткових запитів.
>ось про це я зрозуміти не можу - як клієнт генерує таку кількість запитів? див. [16]
>а ти все про масиви суть не в них. Так у чому сила брат, а сила в правді. Щоправда, така, що при використанні масивів працює швидше.
Відпочинь хлопець. Клієнт - це в загальному випадку, додаток, що формує та надсилає запити до бази даних. Що він далі з нею робить – це не суть.
>Намагаємося знайти її вперше (при цьому аналізується інформація, в тому числі з інших таблиць) - це один запит.
Може уточниш і нам спільно вдасться побудувати запит, який поверне цю жалюгідну сотню записів із 778112?
> а оптимізуєш чомусь швидкість фетчу цих 100 000 записів на клієнта Це питання я поставив чисто з інтересу дізнатися, що порадять люди. Свої міркування щодо цього у мене є.
PS не намагайтеся поставити діагноз неіснуючої хвороби. Видно питання з масивами у вас на форумі дуже хворе.
>Видати питання з масивами у вас на форумі дуже хворий.
Заберизаповнення масивів і залиш тільки Query1.Next. Що швидше стало? :)
>Прибери заповнення масивів і залиш тільки Query1.Next
А тепер прибери Query1.Next і постав ArunloadU[i].id_ves:= IntToStr(i); .
Тепер у тебе є інформація, що саме потребує оптимізації
> Структуру бази даних розробляли у Москві, на замовлення > Держ. комітету з рибальстваОооо. В Москві. Це реально круто! Знаю я, як ці бази розробляють. Виділяється грант на кілька тисяч убієнних єнотів, які розподіляються між наближеними, на 500 баксів береться студент технічного вишу, який з радістю клепає "щось", з чим потім таким, як ти доводиться мучитися.
Не вдаючись у дігноз, можу запропонувати спробувати ClientDataSet - фетчиш у нього всі дані і шукаєш-сортуєш у ньому що завгодно.
Щодо розробки – дійсність саме така.