update velkeho mnozstva dat - cyklus?

Zdravim,

riesim jeden problem ktory som este neriesil, tak sa opytam skusenejsich na radu

Mam tabulku v ktorej je cca 100 000 zaznamov (stale pribudaju nove). Celu tuto tabulku potrebujem raz za cas prejst, vybrat z nej jednu hodnotu z XY. Tuto hodnotu si ukladam do pola. Nasledne vygenerujem url adresu v ktorej su parametre uvedene tieto hodnoty a poslem ju na iny server ktory mi vygeneruje XML. Z toho XML si podla kazdej hodnoty vykonam update daneho riadku, bud 0 alebo 1. (nerobim to po jednom, ale taktiez ulozim do pola hodnoty ktore budu mat 0 a do ineho ktore budu mat 1 a nasledne vykonam 2x update)

Ide mi o to, ze pri url mozem posielat maximalne 300 parametrov, cize to musim nejako rozkuskovat. Tu nastava cas mojej otazky: Ako sa to robi najvhodnejsie? Pokial to cele hodim do cyklu, je velmi pravdepodobne ze mi to vyhodi timeout a padne to. Uz teraz to pri 300 parametroch trva cca 5 az 8 sekund, nechcem mysliet nato co to bude robit ked to zacyklim Cize ako by ste to riesili vy? Idealne bez pridavania dalsieho stlpca v tabulke do ktoreho si ulozim ci to uz bolo skontrolovane

Vdaka..

Ja som riesil raz nieco principialne podobne, ale sluzilo to len na otestovanie funkcnosti skriptu, takze som sa s tym moc neprplal. Nebude to najlepsie riesenie, kazdopadne bolo to rychle (resp. rychlo vytvoritelne nakolko je to len par riadkov kodu a nemusis nad tym premyslat) a funkcne: napisal som si jednoduchy javascript ktory sa stale redirectoval sam na seba pricom pripocitaval hodnotu do premennej v url a podla toho som urcoval, ktora varka za spracuje. Cize ten cas cyklu prenesies na JS, tym padom sa mi nic nezrusilo. Asi som este nastavoval aj prehliadac aby som sa takto mohol stale redirectovat.
Ak ti nahodou staci taketo riesenie, mozes skusit. Na administrativne ucely by sa to teoreticky dalo pouzit.

// Popripade ak mozes, tak si proste nastavis cas spracuvavania na vyssiu hodnotu.

Asi nechapem, co presne trva dlho? Generovanie XML alebo komunikacia s databazou?

My teda dlhotrvajuce skripty riesime obecne tak, ze sa to namrda do cronu, pusti sa to niekedy v noci a je fuk, ze to trva aj patnast minut. Samozrejme po pripojeni k databaze davas AutoCommit = 0 a commitujes az po uspesnom ukonceni, takze sa ti nestane, ze polovicu dat budes mat spracovanu a zmenenu a druhu nie.

Tak musi upravit 100 000 zaznamov vo varkach po 300, cize sa musi pripojit na iny server, pockat kym mu ten spracuje a odosle XML, to potom sparsovat a ulozit do DB. A toto vsetko 333x. Takze cely tento proces je jasne ze trva dlho, poreto ho nechce cyklit.

Tak jako to som pochopil, ale ktora cast toho procesu trva dlho, je docela dolezita otazka. Ak trva dlho to generovanie XMLka kvoli pomalemu serveru, tak ak sa da, treba poslat data POSTom, nie v URL, tam nie je obmedzenie na velkost posielanych dat.
Ak tam robi nejake dlhotrvajuce zazraky v DB, tak pomoct sa tomu asi moc neda-- samozrejme za predpokladu, ze s tou databazou pracujes spravne (mas dobre napisane dotazy; indexy su tam, kde maju byt; ak je to MySQL, tak si si dobre vybral storage engine, z ktorych je teda jeden nahovno a ten druhy este viac).
Ale moc nepoberam, aky je vlastne problem, ze skript dlhsie pobezi... okrem teda vytimeoutovania, co sa da obist, a pripadne teda zamknutia prislusnych tabuliek.