Weblabor

Kukiban egy sosession azonosító kell. A szerveren az állandóan nem szükséges adatokhoz is csak azonosítót kell tárolni. A számla és szállító adatokat gondolom nem kell minden oldalon elérni, és később (két hét múlva) is fel szeretnéd ajánlani a megjegyzett infókat. Ezért szerintem sem kuki, sem session nem jó megoldás rá, csak valami más szerver oldali adattár. Aztán amikor kell, egy azonosító alapján elő lehet venni.

Minél kevesebb fölös memóriát használsz minden szkript futásnál, annál gyorsabb lesz a szkript, és annál elégedettebb lesz a vásárló :)

A probléma két részből áll: az egyik a session holmi. Ide azt mondom, hogy sok mindentől függ: pl. a webszerver egy processzének odaadott maximális memóriától, a PHP egy futásakor odaadott max memóriától (ez az az ominózus 8MB), a betöltött PHP fájl és az annak lefordított bájtkódjától, és a PHP szkriptben felhasznált adatok hosszától (ide tartozik pl. a session információ is, és a cookie-k is). Jah, a session információ max hossza ugye attól is függ, hol tárolod ezeket. Ha fájlban, akkor a maximális fájlméret fontos lehet (pl. ne tedd win98 alá a produktív szervert). Ha adatbázisban, akkor a maximális LOB hossz lehet a szűk keresztmetszet.

Mindenesetre nem jó ötlet hatalmas adatokkal dolgozni, mert az jócskán megeszi a teljesítményt. A rossz kódokból meg csak az kér, aki nem tudja, hogy a kóklereket kíméletlenül el kell hajtani. Én pl. nem tárolnék 300k-t sem a session-ben.

A másik félreértés abból eredhet, hogy a számla- és szállítóadatok cookie-kben vannak. Szerintem ezeket egyszerűen bele kell rakni az adatbázisba. Hiszen egyrészt a cookie adatbázis a kliensen bárki számára olvasható (már azok olvashatják, akik a klienst használhatják), és nem hordozható (pl. más gépről bejelentkezve nincs ott a megszokott cím). Ide az is bejátszik, hogy a nagy worm hullámok miatt már csak az nem törhet be a windows kliensekbe, aki nem akar. Egy szerverbe már sokkal ritkábban törnek be, mint az azt használó kliensekébe átlagosan.
---jul