Dotaz: Python a opakovany vypis dat z databaze

[Tomis]

Dobry den, chtel bych ze zeptat jak spravne opakovane vypsat hodnoty nactene z databaze. Zde cast kodu:

kody_all = cur.execute(SELECT)
#kody_all = (('010',),('020',),('030',))

for kod in kody_all:
  print kod[0]

print " a jeste jednou....."

for kod in kody_all:
  print kod[0]

con.close()

Kdyz kody_all nactu z databaze, tak pri prvnim behu smycky FOR se vsechny udaje vypisou, ale pri behu te dalsi smycky se uz nevypise nic. Kdyz kody_all nastavim pomoci toho zakomentovaneho radku, tak vypsani probehne v obou smyckach.

Jedine co mi funguje je pred kazdou smyckou FOR pridat znova kody_all = cur.execute(SELECT) , ale to znamena, ze dojde k opakovanemu nacteni dat z DB? To mi neprijde zrovna spravne.....

Muzete mi prosim poradit, jak ty udaje z DB vypsat opakovane? Dekuji.

---

---

Odpovědi

[divbyzero]

Dobry den, co si ulozit vysledek do mezipromenne?

kody_current = kody_all

[Kit]

Problém spočívá v tom, že proměnná kody_all není pole, ale iterovatelná strukrura, která se bohužel neumí "převinout na začátek".

Správně bys to měl překopírovat do nové struktury, která se už bude chovat dle tvých potřeb. Nejlépe do nějakého objektu nebo přinejhorším do pole.

[Kit]

Teď na to koukám, zkus tohle:

kody_all = cur.execute(SELECT).fetchall()

[Tomis]

Jo, moc dekuji, tohle uz funguje. Muzes mi prosim jeste trochu naznacit, co se tim fetchall() zmenilo?

[Kit]

Ze zmíněné iterovatelné struktury (viz výše) se stalo obyčejné pole, resp. seznam.

[eee]

To neni dobre vysvetleni. Spravne vysvetleni je, ze execute vraci kurzor, ktery kazdym zavolanim vrati z db jeden radek. Volanim fetchall() primejeme kurzor vratit cely vysledek jako list radku.

[Filip Jirsák]

Ten váš kód postupně donačítá výsledky z databáze – bude tedy fungovat i pro hodně velké objemy dat, protože se vždy přenese jenom část výsledků. Na druhou stranu se ve výsledcích můžete pohybovat pořád jen dopředu, takže když je potřebujete vypsat vícekrát, musíte dotaz zavolat opakovaně v jedné transakci (a nastavit správnou úroveň izolace transakcí, aby vracel vždy stejné výsledky). Upravený kód dělá to, že nejprve načte všechny výsledky z databáze do paměti, takže je pak můžete procházet libovolně. Nevýhoda je, že se vše načte najednou do paměti, takže jste omezen velikostí dostupné paměti a víc výsledků takhle nezpracujete.

[Kit]

Pokud jsou data načítaná z databáze jen menšího rozsahu (řekněme < 1 MB), tak se o takové nevýhodě vůbec nemá smysl bavit. Pro většinu běžných případů tedy výhody kompletního načtení převažují.

Za nejlepší řešení však stále považuji použití načtených dat pouze 1×. V opačném případě mi v takové aplikaci "něco smrdí".

[Filip Jirsák]

O rozsahu dat nic nevíme. Pokud to budou stovky GB, nemá zase vůbec smysl bavit se o tom, že se to celé načte do paměti…

[Tomis]

Dobry den, databaze je sice velka (cca 100GB), ale ja nacitam pouze 3 sloupce z jedne tabulky. a nacitam vzdy jenom data z minuleho dne, takze se uz nijak nemeni. Tech zaznamu za den je kolem 5000. Takze ten fetchall() mi takto vyhovuje.

[Kit]

Pokud to budou stovky GB, nemá zase smysl bavit se o dvojitém načítání. Je nutné to načíst jednou a ihned zpracovat podobojí.

[Filip Jirsák]

Pokud to jde. Pokud bude potřeba to poslat jako soubor přes HTTP a v hlavičce bude hash toho souboru, nic jiného vám nezbyde. Jasně, jsou to extrémní příklady. Jde spíš o to, že „načíst všechno do paměti“ je jednoduché řešení pro jednoduché případy, které ale neškáluje. Proudové zpracování se hodí nejen pro velký objem dat, ale také umožní třeba paralelní zpracování (ať už využití více jader CPU na jednom stroji, nebo zpracování na více uzlech v cloudu).

[Kit]

Tady na fóru se řeší hlavně jednoduché příklady, u kterých to škálování chybět nebude.

99 % běžných případů vyřeší inženýři a to zbylé 1 % přenechají doktorům, aby se měli v čem rýpat a aby také něco dělali

A ten velký soubor? Uložím ho do tempu, spočítám hash a obojí pošlu klientovi. Do databáze se podruhé hrabat nebudu, protože se jistě mezitím změnil její obsah a držet ji celou dobu pod krkem by také nemuselo být zrovna košér.

A když už jsme u těch velkých objemů dat, tak hash používám jako klíč k přístupu k takovým datům a proto bych ho klientovi jednoduše přibalil.

[blondak]

Neznám sice Python, a ani nepíšete na jaké to má být databázi, ale třeba mysql v php má funkci mysql(i)_data_seek, pro sqlite sqlite_rewind