ugrás a tartalomhoz

webshop "minimum" szerkezet

Pepita · 2012. Aug. 28. (K), 06.59
Sziasztok!

Egy saját fejlesztésű webshopot tervezek, kicsit megakadtam az adatbázistervnél.
Az a gondom, hogy lehetőleg minél kevesebb táblából és műveletből szeretném megoldani, de nem tudom, hogy elég jól gondolkodok-e. Eddig megvan:
- Termékek két táblában, mert kategóriák is kellenek. A termékek egyediek, készletezni nem kell (csak kapcsolni, hogy van/nincs), mindenből kétféle kiszerelés van. Ez utóbbit megoldottam - nem túl szép megoldás - úgy, hogy 'kiszereles1' és 'kiszereles2', 'ar1' és 'ar2', ..., így táblán belül maradt, nem kell több kiszerelést tudnia. Az, hogy épp kapható-e, szintén 'vanbelole1', ...
- Vásárláshoz van kosár tábla, ebbe pakolnak a vásárlók user_id-t, termek_id-t, kiszerelést, stb.
- Felhasználókezelés komplett kész, itt nem érdekes.

A problémás a megrendelés tárolása/kezelése. Sehogy sem tudom egy táblában ésszerűen elképzelni. Amit kb. tárolni szeretnék benne:
- Megrendelő adatai (részben a felhasználók táblájából másolva) név, cím, stb.;
- Megrendelés ideje, végösszeg, felhasználói megjegyzés (ahol pl. leírhatja, hogy nem a saját nevére kér számlát, másik címre szállítást)
- Maguk a megrendelt tételek (név, mennyiség, egységár, érték)

Az első kettő megrendelésenként egy adat, a tételek több. Emiatt gondoltam két táblára, kulcsként a megrendelés id-vel. Így viszont az üzemeltető részére adott "rendelések" lekérdezése "sokSELECTes" lesz. Ez nem feltétlenül baj, csak én eléggé erőforrás-spórolós vagyok. (A felhasználói adatokat is részben ezért másolom, másrészt azért, mert ha megrendelés után, de még annak kezelése előtt módosít pl. címet.)

Abban kérném a segítségeteket, hogy ez az elgondolás mennyire helyes/helytelen, lehet-e rajta - elméletileg - optimalizálni valahol.
 
1

Megrendelt tételek

Hidvégi Gábor · 2012. Aug. 28. (K), 07.34
Régen csináltam egy webshopot, és emlékeim szerint úgy oldottam meg, hogy a megrendelt tételek a kosár táblában maradnak, csak megrendelés után a felhasználó kap új, üres kosarat, a régit pedig a megrendeléshez csatolom. A többi adat mehet egy táblába.
2

arra is figyelj oda, hogy a

szabo.b.gabor · 2012. Aug. 28. (K), 08.38
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.
3

Biztos?

Poetro · 2012. Aug. 28. (K), 10.45
És ha lesz valamihez 3. 4. kiszerelés, akkor újabb mezőkkel fogod bővíteni a táblát??? Ez így nem túl szerencsés elgondolás.
4

Ennyire gáz JOIN -t használni?

dropout · 2012. Aug. 28. (K), 14.40
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?
5

Nem gáz

Hidvégi Gábor · 2012. Aug. 28. (K), 15.29
Nyugodtan lehet JOIN-t használni; a Pepita által vázolt táblaszerkezetnek akkor van értelme, ha biztosan tudja, hogy nem fog megváltozni az idők folyamán, így egy lekérdezés gyorsabb valamennyivel, ha egy helyen van minden. Szerintem erre kicsi az esély, én is külön tenném az árakat.
6

Mindenkinek köszönöm!

Pepita · 2012. Aug. 29. (Sze), 01.01
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:
Maguk a megrendelt tételek (név, mennyiség, egységár, érték)
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.
7

Végeredmény

Pepita · 2012. Aug. 31. (P), 01.25
Elnézést, de nem a teljes tervet közlöm, csak a sémát.

- Termékek összesen három táblában: 'termekek', 'kategoriak', 'kiszerelesek'. Utóbbi azért, hogy lehessen tetszőleges számú kiszerelés, ha ebben a projektben nem is kell.

- Kosár egyetlen 'kosar' táblában, itt már nem (csak) azonosítókat, hanem a kosárba tett termék (kiszerelés) konkrét (pillanatnyi) adatait is tárolom.

- Megrendelés: mint előzményekben, 'rendeles' és 'tetelek' táblákban, user, termek, kiszereles tényleges adataival.

Szerintem így jó lesz, ha nem, majd módosítom.