Weblabor

arra is figyelj oda, hogy a megrendelés táblában ne csak termék_azonosítót tárolj, hanem minden adatot a termékről (már amit relevánsnak gondolsz). így kivédheted hogy termékadat változáskor (ár) a megrendeléseid is változzanak.

Kicsit off, mert végülis a kérdéshez csak közvetve van köze, de tényleg ennyire gáz lenne JOIN-t használni, hogy így kerüli az ember?

Sejtettem, hogy többféle választ kapok, de azt nem, hogy ennyit, köszönöm, sokat segítettetek! Egyben válaszolnék, szám szerint:

1.: Ezen még gondolkodnom kell, de valószínűleg én külön táblában fogom tárolni a már megrendelt tételeket, mert a kosár lesz az egyszerre legtöbb Júzer által "mozgatott" tábla, emiatt abból célszerű takarítgatni a tételeket, ha már nem kellenek oda. Viszont így lehetne spórolni egy táblát... - még nem tudom.

2.: Nagyon igaz figyelmeztetés, idézem magam: Itt nem részleteztem úgy ki, csak a felhasználói adatoknál, de én is így gondolom.

3.: Ebben az esetben biztos, hogy nem lesz 3-4. kiszerelés, viszont elrontom így a terv újrahasznosíthatóságát, tehát nagyon is megfontolandó. (Az én szemléletemben mindig ott van, hogy ha teljesen egyedinek tűnik is egy feladat, akkor is lehetőleg úgy oldjam meg, hogy máskor/máshol is jó lehessen. Hátha "véletlenül" egyszer csak a fiókomban lesz egy komplett CMS.)

4.: Nem csak a JOIN miatt (ha nagyon sok tételed/felhasználód van, akkor lehet gond vele), hanem az esetleges adatváltozás miatt is. De "1 JOIN / rendelés" már van benne, mert a tételek külön vannak. (Persze lehet, hogy beágyazott SELECT lesz, de még nem ott tartunk.)
Például: a megrendeléseket az üzemeltető szombatonként küldi el futárral. Gipsz Jakab csütörtökön megrendel x tételt. Tudja, hogy el fog költözni, ezért a megjegyzésbe beírja, hogy csak akkor kéri a szállítást, ha ezen a szombaton sikerül szállítani. Ráklattyol a megrendelés gombra, ezután saját adatai közt megváltoztatja a címét, nehogy elfelejtse, és míg a költözéssel bajlódik, úgysem fog rendelni semmit. Nyugodtan lefekszik aludni, az üzemeltető pedig szombaton kiküldi neki a cuccost az új címére, ahol senki sem veszi át. És mindketten haragszanak - rám, és jogosan. Ugyanez áll a termékek adataira is, az üzemeltetőnek kötelessége azon az áron (és minden egyéb paraméterrel) számlázni, szállítani, ami a megrendelés idején ki volt írva. Tehát ha nem másolnám át a termékek adatait, akkor az üzemeltető csak bezárt shop mellett és minden addigi rendelés teljesítése után emelhetne pl. árat. Ez nagy kényelmetlenség lenne neki - ráadásul feleslegesen.

5.: Itt ugye a kiszerelésről (+ ár, van belőle,..) van szó, azt l. 3. A gyorsaságon kívül van még egy dolog: azt a terméket, amelyikből egyik kiszerelés sem kapható, nem kell (szabad) kilistázni a shopban. Egyébként radio-val választ a kiszerelések közül, ha csak az egyikből van, akkor a másik disabled, és amelyik disabled, az nem lehet checked. (Könnyítésként az első - ha van - mindig checked, mert abból jóval többet szoktak venni.) Ezt a mutatványt sokkal egyszerűbb fixen két mező alapján megvalósítani, mint tetszőleges számún. Ha elég frappáns (és gyors) megoldási ötletem lesz erre a terméklistás játékra, akkor mindenképp külön veszem a kiszereléseket (-> újrafelh.).

Sikerült sokkal szélesebb látókörrel áttekintsem a feladatot - nektek köszönhetően. Eredménnyel visszajövök, üdv.