mysql lekérdezés eredmény tárolása

szarkab képe

Sziasztok!
Szeretnék a főoldalra egy mysql lekérdezést kitenni.
Az viszont nem lenne jó hogy minden oldaltöltéskor a lekérdezés lefusson, mert az adatbázist ahonnan lekérdezem nem szeretném ezzel terhelni. Egy héten egyszer elég lenne ha a lekérdezés lefutna, az eredmények pedig állandóan kint lennének.
Van valami ötletetek hogy lehetne megoldani?

Fórum: 
Sk8erPeter képe

Saját adattáblában eltárolod egy mezőbe a legutóbbi lekérdezés dátumát, a legutóbbi lekérdezés tartalmát. Ezt a tartalmat (a legutóbbi rekordot dátum szerint rendezve) jeleníted meg minden oldalbetöltéskor, persze szépen szabályosan, a Drupal adatbázis-kezelő API-ját használva. Cron futtatásakor (legyen ilyen, mondjuk naponta, és működjön) lekérdezed az ebben a táblában utoljára eltárolt mezőnek a dátumát, ha a jelenlegi dátumhoz képest több, mint egy hete volt, akkor lekéred a külső adatbázisodból az adatot.
Szerintem nem mindig egy rekordot kellene felülírogatnod, hanem eltárolni a korábbi adatokat is, hátha később szükség lesz rá, le akarod kérdezni a múltbelieket is, esetleg abból listát megmutatni (aztán bizonyos időközönként törölhetsz is a korábbiakból automatizáltan).
Saját modul kódolása nélkül ez nem fog menni, gondolom ez egyértelmű, mivel a saját, Drupal által használttól eltérő adatbázissal való kommunikációt, a megfelelő táblából való lekérdezést neked kell megoldanod.

0
0
nevergone képe

Nem tudjuk a pontos részleteket, azt sem, hogy milyen méretű adatot kellene tárolni. Én egy érték tárolásáért (nekem úgy jött le, hogy nem kell a régi eredményt tárolni) én biztosan nem kezdenék saját adattáblával. Mert ugye akkor abban csak egyetlen rekord lenne, ha pedig a régi adat nem kell, akkor minek tartogatni.

Valóban kell ehhez programozás, de azért ne kezdjünk el rögtön ágyúval verébre lövöldözni. :)

0
0
Sk8erPeter képe

Valóban nem tudjuk a pontos részleteket, ahogy ezt sem:

nekem úgy jött le, hogy nem kell a régi eredményt tárolni

nekem nem jött le sehogy, mert nem osztotta meg. :) De elképzelhető, hogy mégis szüksége lesz ilyenre, például korábbi adatok listázásához (ahogy Te is írtad, ezt nem tudjuk). Ha nem, akkor meg az is jó lesz, amit Te ajánlottál, csak akkor két variable-t kell használni, a legutolsó külső adatbázisból való lekérés időpontja számára, plusz magára a tartalomra (és az teljesen jó is lesz). De épp Te mondtad ki a kulcsmondatot, hogy nem tudunk elég részletet ahhoz, hogy egzakt választ mondjunk, így az sem eldönthető, hogy a Te megoldásod elegendő lesz-e (honnan tudod, hogy ez "ágyúval verébre"? Ha mondjuk tízféle adatot is tárolni kéne hozzá, akkor a variables táblában tárolás már gányolásszagú, de feladattól függ). Majd ő eldönti, hogy neki melyikre van szüksége, elég lesz-e a Drupal variable-ben tárolás, vagy sem, így legalább kapott kétféle megközelítést, szerintem az sosem baj. :)

0
0
nevergone képe

„Ha mondjuk tízféle adatot is tárolni kéne hozzá, akkor a variables táblában tárolás már gányolásszagú, de feladattól függ).”

Ez igazából elvi kérdés, én ezt is egy asszociatív tömbbe tenném és egy változóba pakolnám szerializálva, akár a frissítés időbélyegét is. Szerintem sokat nem is lassítana rajta, de ha mégis tíz változó lesz, az is rugalmasabb megoldást jelent.
Feltéve persze, ha nem kell a régi értékeket tárolni. :)

0
0
Sk8erPeter képe

Ez igazából elvi kérdés, én ezt is egy asszociatív tömbbe tenném és egy változóba pakolnám szerializálva, akár a frissítés időbélyegét is.

Jelen esetben mivel sajnos így is-úgy is serializálva kerül be a variable táblába minden adat, még akár ezt a merényletet is el lehet követni.
OFF: Ettől függetlenül ha már szóba került, szerintem nagyon túlzásba viszik a modulkészítők ezt a serializálás-mániát Drupalban, erre legrosszabb példa a Field group: amikor van 40 fielded egy adott content type-nál, és ezek teljes hierarchiája (!) labellel és minden egyébbel együtt be van nyomorítva serializálva a szokásos semmitmondó data mezőbe, az szerintem botrány, elképesztő erőforrás-igényes és lassú lesz, ráadásul még egy normális query-t sem lehet rá írni (és igen, sokkal értelmesebb és gyorsabb lenne akár 40 külön sorba bontva). Az adatbázis-normalizáció sajnos sokszor elfelejtődik modulírásnál...

0
0
szarkab képe

Köszönöm a válaszokat. 3 változóm van úgyhogy akkor egy tömbbe mentem le őket. Nem rossz ötlet a régiek eltárolása is, de most még elég ha mindig felülírogatom.

0
0