Webáruház és Raktárkezelő
Sziasztok az alábbiban kérném gyors segítségeteket.
Szerintem lehet van is erre már jól bevált adatbázis-szerkezet, de nekem még nem sikerült kitalálni.
A feladat: Van egy web áruház, és ehhez kapcsolódóan kezelni kéne a raktárkészletet (kiadni, rendelni,stb.)...
Azt kérték, hogy ha van egy termék: pl. egy konkrét üdítő, akkor az adott terméknek lehessen viszonylag korlátlan, és szabad tulajdonsága is, ami igazából más terméket takar raktározás szempontjából.
Ezt úgy kell elképzelni hogy van egy adott márkájú üdítőital, akkor az egy terméknek jelenjen meg az oldalon akkor is, ha különböző ízben, vagy kiszerelésben is kapható.
Tehát ha az ügyfél kiválasztja az XYZ üdítőt, akkor megrendeléskor ki tudja választani: milyen ízben (mondjuk, legyen 3 íz: alma, körte, szőlő) és miylen kiszerelésben szeretné megvásárolni (mondjuk, legyen 3 kiszerelés: 0.5 liter, 1 liter, 2 liter).
Ha a fenti példánál maradunk, akkor az adott XYZ terméket 9 féle variációban rendelhető max. meg.
Viszont raktárkészlet szempontjából a variációk max. 9 féle terméket jelent. Tehát ott nem kezelhető egyben az XYZ üdítőt, mert ha az ügyfél szeretne egy 2 literes szőlőt, akkor nem az érdekel, hogy van –e XYZ üdítő raktáron, hanem az, hogy az adott típus van –e, és annak mi az ára, stb..
Tehát kicsit olyan, mintha az adott termék ha minden variációban létezik, akkor 9 különböző termék lenne, de a shop szempontjából ez a 9 termék csak egyetlen egy termék lenne különböző tulajdonságokkal, és árakkal.
Egy egy terméknek vagy van változó tulajdonsága vagy nincs. Ha van, akkor tetszőleges számú tulajdonsággal rendelkezhet, és ezek tetszőleges értékkészletük lehet.
Tehát ha ezt a kettő rendszert egyben szeretném kezelni, akkor hogyan lehetne a legfrappánsabban kialakítani az adatbázist?
Gyors segítségeteket előre is köszönöm.
Zoli
■ Szerintem lehet van is erre már jól bevált adatbázis-szerkezet, de nekem még nem sikerült kitalálni.
A feladat: Van egy web áruház, és ehhez kapcsolódóan kezelni kéne a raktárkészletet (kiadni, rendelni,stb.)...
Azt kérték, hogy ha van egy termék: pl. egy konkrét üdítő, akkor az adott terméknek lehessen viszonylag korlátlan, és szabad tulajdonsága is, ami igazából más terméket takar raktározás szempontjából.
Ezt úgy kell elképzelni hogy van egy adott márkájú üdítőital, akkor az egy terméknek jelenjen meg az oldalon akkor is, ha különböző ízben, vagy kiszerelésben is kapható.
Tehát ha az ügyfél kiválasztja az XYZ üdítőt, akkor megrendeléskor ki tudja választani: milyen ízben (mondjuk, legyen 3 íz: alma, körte, szőlő) és miylen kiszerelésben szeretné megvásárolni (mondjuk, legyen 3 kiszerelés: 0.5 liter, 1 liter, 2 liter).
Ha a fenti példánál maradunk, akkor az adott XYZ terméket 9 féle variációban rendelhető max. meg.
Viszont raktárkészlet szempontjából a variációk max. 9 féle terméket jelent. Tehát ott nem kezelhető egyben az XYZ üdítőt, mert ha az ügyfél szeretne egy 2 literes szőlőt, akkor nem az érdekel, hogy van –e XYZ üdítő raktáron, hanem az, hogy az adott típus van –e, és annak mi az ára, stb..
Tehát kicsit olyan, mintha az adott termék ha minden variációban létezik, akkor 9 különböző termék lenne, de a shop szempontjából ez a 9 termék csak egyetlen egy termék lenne különböző tulajdonságokkal, és árakkal.
Egy egy terméknek vagy van változó tulajdonsága vagy nincs. Ha van, akkor tetszőleges számú tulajdonsággal rendelkezhet, és ezek tetszőleges értékkészletük lehet.
Tehát ha ezt a kettő rendszert egyben szeretném kezelni, akkor hogyan lehetne a legfrappánsabban kialakítani az adatbázist?
Gyors segítségeteket előre is köszönöm.
Zoli
Oldd meg helyettem
Nem old meg helyettem
A cég szeretne egy ilyet. Kiadta nekünk.
Nannak elképzeléseink, és terveink, de mivel ez szerintünk egy lerágott csont lehet (csak idáig mi nem csináltunk ilyet), azért kértem volna tippeket a szerkezet mikéntjére.
Ilyen alapon akkor senki semmit ne kérdezzen.
nagy vonalakban
Temészetesen van egy parameter tábla amiben az egyes temékek paramétere található és van egy tábla amiben a felvehető értékek. A paraméter tábla többek közott tartalmazza hogy mi a parameter neve (pl. szín) meg azt is mely termékhez tartozik, és azt is, hogy ez az adott termék hanyadik paramétere a terméknek (ez a később a raktárazonosító miatt fontos). Az érté tábla meg a kiírandó érték mellett egy valódi értéket is tartalmaz, hogy a rendesz ne ékezetes és egyéb bizonytalan adatokkal dolgozzon.
A termékeknek két azonosítója van.
Az egyik maga a terméké (pl. XYZ üdítő=1234), és egy másik ami a raktározó rendszerbéli azonosíró. Eme második egy generált azonosíró, és az adott termék azonosítójából és annak paraméter értékeiből tevődik össze. pl.: 1234_05_barack (1233=üdítő, 05= 0.5liter, barack=íz)
(Több íz vagy kiszerelés eseten a termekazonosító ugyanaz minden esetben.)
A raktározó az összes egyéni ragtárazonosítót külön kezeli,és tudja egy termékből milyen variációk léteznek, mennyibe kerülnek, van -e raktáron vagy rendelni kell stb...
(Amilyen variáció nincs az nem foglal külön rekordot.)
A webáruház csak a teemékazonosítókat nézi. Egy azonosítóból csak egyet listáz ki (esetleg jelezhető melyiket), és a paraméterek alapján hozzáteszi a választható paramétereket. Természetesen ha a kiválasztott paraméterek alapján kell az egyéni ár,vagy hogy van -e az adott íz abból a kiszerelésből,és ha igen mennyi, akkor azt is gyorsan ki tudja keresni a rendszer a generált raktárazonosító alapján.
Kérdés,hogy ettől jobb megoldás létezik -e?
Amit mi látunk most hátránynak az a javítási probléma.
pl.valaki ízhelyett színekkel veszi fel az üdítőket,és mindent át akarnának írni mikor erre rájönnek fél évvel később. Vagy egy pzsgőtablettánál felveszik azt hogy pezsgő típusú, és az ízt második paraméternek. Majd rájönnek mindegyik pezsgőtabletta pezsgő tulajdonságú,így jó lenne ezt a paramétert eltüntetni. Viszont ez a raktárkód változását is jelentheti... STB..
(Az elírásokért bocs,de mobilról ment ez)
1. gondolj arra is, hogy az
2. az egyes opciókhoz rendelj raktári kódot, és máris könnyen azonosítható a dolog.
Csak így kíváncsiságképpen, hogy oldod meg a raktárkészlet pontos követését webáruházban? :)
Ezerintem ezt teljesíti
A mit mi gondoltunk, az szerintem az elsőt teljesíti.
Pont az a lényege, hogy amennyiben nincs mondjuk barack ízből 2 literes, akkor azt nem veszik fel a termékek közé. Lehet így a vonaton nem részleteztem eléggé a dolgot, de nem úgy gondoltuk, hogy amikor egy termékhez tulajdonságokat veszünk fel, akkor a termékek közé az összes variáció legenerálódik, hanem csak azok kerülnek bele, amit az adminisztrátor ezek közül fel is vesz.
Tehát lehet lesz 1234_20_barack és 1234_10_barack és 1234_10_alama, de a példádnál maradva nem biztos, hogy lesz felveve_1234_20_alma, mert olyat nem forgalmaznak.
A másodiknál nem teljesen egyértelmű.
Ha arra gondolsz, hogy az egyes tulajdonságok variációiból mixelhető termékek közül amit felveszünk annak legyen mindnek egy egyéni raktárkódja is, akkor ugyanarról beszélünk. Csak mi úgy képzeltük el, hogy ezt a rendszer generálva úgy, hogy abban könnyen akár keresni is lehessen, mivel jelentést hordoznak. (tehát a paraméterértékek alapján.)
Persze ez a jelentés egyben hátrány is lehet, ha javítani kell.
Ha viszont másra gondolsz (pl. az egyes paraméterekhez rendelnél raktárkódost), akkor azt kérlek kicsit fejtsd ki.
Ja még egy váalsz
"Csak így kíváncsiságképpen, hogy oldod meg a raktárkészlet pontos követését web áruházban? :)"
Ha kiválasztom a web áruházban az XYZ üdítőt, akkor ez azt jelenti, hogy az 1234 termék azonosítójú termékekre vagyok kíváncsi.
Az adatbázisban ezek szerepelnek
Termék adattábla:
termékkód | raktárkód | konkrét termék | termék mennyiség (persze most csak az egyszerűség kedvéért tettem ide)
1234 | 1234_05_alam | XYZ üdítő 0.5 literes alam | 10
1234 | 1234_10_alam | XYZ üdítő 1 literes alam | 20
1234 | 1234_05_szolo | XYZ üdítő 0.5 literes szőlő | 5
1234 | 1234_10_szolo | XYZ üdítő 1 literes szőlő | 30
1234 | 1234_20_szolo | XYZ üdítő 2 literes szőlő | 8
Tulajdonságok tábla:
termékazonosító | tulajdonság sorrend | tulajdonság neve
1234 | 1 | kiszerelés
1234 | 2 | íz
Tulajdonság érték tábla:
termékazonosító | tulajdonság azonosító | megjelenő érték | valódi érték
1234 | 1 | 0.5 liter | 05
1234 | 1 | 1 liter | 10
1234 | 1 | 2 liter | 20
1234 | 2 | alam | alma
1234 | 2 | szőlő | szolo
A web áruház mikor kiírja az XYZ terméket, akkor ki tudja keresni, hogy milyen tulajdonságok lehetnek (mátrix).
Azt is tudja, ebből csak 5 féle termék variáció elérhető, és meg is tudja határozni miből mennyi van.
Nekem ez működőképesnek tűnik
Szerintem ez is működik, de tartok tőle, hogy nagyobb mennyiségű termékbejegyzés esetén nagyon lelassulnak a lekérdezések a táblaösszekapcsolások miatt.
Valószínűleg félreértetted, a
Rendben,
Szerk.: Ja! Fentebb...
Termék csoportok
Vannak a termékek amik termék csoporthoz vannak rendelve
termékcsoport tábla:
id, nev, leiras, kiemelt, etc.
Termék tábla:
id, termekcsoport_id, leiras, kiemelt, iz, méret, etc..
A felvitelnél pedig szépen meg lehet adni a termékcsoportot is, ha nem, akkor a termék marad "csoporttalan"
Ha szépen megcsinálod, akkor a termék tulajdonságai megegyeznek a termék csoportéval, és igy ha valamiért a csoportban egyedi leirás, etc. kell akkor a termék megfelelő mezőjének kitöltésével egyszerüen felül irod a szükséges tulajdonságot.
Termék csoportok
Ráadásul fontos a tulajdonságok dinamikus kezelése, mert nem meghatározható előre milyen tulajdonságok lesznek.
Ruhánál: szín és méret
Tablettánál: bogyószám (kiszerelés)
Üdítőnél: űrtartalom (kiszerelés) és íz
Krémnél: űrtartalom (kiszerelés)
Szemüvegnél: dioptria
stb..
Én először is csinálnék egy
Amit írtál, a tulajdonságok dinamikus kezeléséről...hát szerintem aránylag jól fel lehet készülni előre. Pl senki sem fog arckrémet viszkozitás, vagy baseball ütőt Vickers keménység alapján keresni.
Én először is csinálnék egy
Arra kell készülni, hogy az üdítőtől, a tv-n keresztül, a fekvőpadon, WC papíron és vibrátoron át mindent árulnak majd.
Ráadásul indulásként csak 2-3 terméknek lesz eleve más kiszerelése (de nem külön termékként akarják kezelni az oldalon ezt sem), de feladatként mindenre alkalmassá kell tenni (ez fontos kitétel volt).
Mivel sok terméknek pl. nincs külön típusa, akkor minden bekerül csoportként, majd fel kell venni egy nincs jellemző egyéni tulajdonsággal.
Amit kaptunk, hogy nem akarnak korlátot látni. Ha a butyik gumijának a színét akarják felvenni, akkor azt is fel tudják venni.
Ha meglenne, hogy műszaki cikkeket, vagy valamilyen jól behatárolgató termékcsoportnak készülne a rendszer, akkor sokkal egyszerűbb lenne.
Akkor is ha a WEB és a készletnyilvánító rendszer nem fonódna össze, mert pl. csak web oldalról nézzük, akkor sokkal egyszerűbb a probléma.
Tehát egyik oldalt (Web áruház) a terméket tulajdonságokkal akarják látni, másik oldalt pedig (raktározó rendszer) pedig minden létező variációt külön-külön (hogy tudjanak nagykerekből beszerezni, szállítani, stb.).
"Mivel sok terméknek pl.
Nem tudom, jól értelmeztem -e ezt a mondatot, de nekem ebből az jött le, hogy nem akarod normalizálni az adatbázist. Jól értettem?
Nem rossz az
Félreértettem valamit?
Nem
Ez arra vonatkozott, hogy lehet felesleges minden egyes terméket azért több táblába is tárolni, mert nincs is több variációban.
Ezért csak termékek táblában gondolkodtunk.
De nem azt szeretnénk, hogy pl. felveszek 80 plusz mezőt és ebbe beírunk értéket ha az adott tulajdonság értelmezhető.
Igazából a mi ötletünk alapján az volt, hogy egy mező van ami a raktár azonosító, és ez tartalmazza az összes tulajdonságértéket, mert maga a tulajdonságok alapján generálódik.
Ha van 3 termék: 1234=tabletta, 1235=hurkapálca, 12346=festék, akkor ha ezek a termékazonosítók esetén:
1234_2
1234_4
1234_6
1235_10
1235_20
1236_60
1236_70
a 2, 4, 6 az mondjuk a kiszerelést jelzi (hány szemes)
a 10, 20 a hurkapálcák hosszát
a 60, 70 pedig az jelöli, hogy a festék hány négyzetméterre elegendő
Tehát a fenti 7 termék szerepel az adatbázisban, mert raktár és beszerzés miatt ez a 7 fizikailag létezik.
A web áruház viszont csak 3 terméket lát (termékazonosító alapján), aminek lát több variánsát.
Azt hogy az 1234 terméknél szemszámot jelölnek a variációk, azt a tulajdonságtáblából tudja a rendszer.
Most csak azt modelleztem ami egyszerűbb (egy terméknek csak egy tulajdonsága van), de akkor válik érdekesebbé a dolog ha több tulajdonsága is lehet a terméknek (olyan ami alapján több fizikai termékről beszélhetünk raktár szempontjából).
A lehető legrosszabb módon
"Ez arra vonatkozott, hogy lehet felesleges minden egyes terméket azért több táblába is tárolni, mert nincs is több variációban."
Nem értem, hogy ez miért lenne felesleges.
.
Természetesen így is sok tábla van, de a fő probléma szempontjából írtam az egyet.
Mivel az összetettebb és részletesebb szerkezete a raktárkezelőnek van, ezért abból indultunk ki, mert ott minden termékvariánsnak szerepelnie kell, mivel az a raktár szempontjából mind különálló termék. Megrendeléseket is az alapján kell kezelni....
Aztán van egy web áruház ahol egyes termékek úgymond csoportosítva vannak.
Miért gáz annyira, hogy nem két különálló rendszert szeretnék összekapcsolni?
Nem akarok egy táblát amiben az összes termék benne van (raktár). Majd egy másikat, amiben benne vannak azok a termékek amiket a weboldalon összetartozónak tekintünk (termékcsoport). Majd valahogy meg kell a csoportok egyes tagjainak a specifikus tulajdonságát is határozni egy táblában és egy másikban azt is, hogy milyen értékeket vehet fel. Aztán egy 5.-ben azt, hogy a lehetséges kombinációk közül melyik alkot valós fizikai terméket a raktáradatbázisban, és még ezt is összekapcsolni egy kapcsolótáblával (akár végtelen tulajdonságkombinációban, végtelen dimenzióban).
Természetesen ezt is néztük, és működhetne így is, de ha több tulajdonság is él egyszerre egy terméknél az már gondot okozott.
Mi csak ehhez képest két dolgot csináltunk:
- kihagytuk a csoporttáblát, és helyette az egy WEBES azonosítón lévő termékekre mondtuk azt, hogy azok tartoznak össze.
- nem egy külön kapcsolótábla határozza meg, hogy az össze tartozó termékek (WEB irányból) miben térnek el egymástól, hanem maga a raktár-azonosító hordozza ezt az információt (ez kialakítása alapján egyszerre több tulajdonságot is kódol). Tehát a gép maga az elérhető variánsok kiolvasásával, rögtön tudja, hogy azok egymástól miben térnek el (természetesen a tulajdonságtáblát azért segítségül kell hívni).
Természetesen mint írtam látjuk ennek is 1-2 negatívumát is adminisztráció szintjén.
Ezért is született a kérdés...
Ui.:Bár most így leírás közben gondolkodva azt is csinálhatja az ember, hogy nem a raktár-azonosító hordozza ezt az infót, hanem egy másik plusz mező.
Természetesen lehet csoporttábla meg minden, de ez az itt elhangzottal alapján csak annyit old meg, hogy melyik termékek tartoznak össze.
De arra még nem jött frappáns megoldás, hogy ha teljesen véletlenszerű tulajdonságok alapján akarják csoportosítani (akár 2-3-4 tulajdonsággal is egyszerre), akkor az miként írható le szépen. És úgy érzem ez az egyik méregfoga az egésznek. Hogy mezőben, vagy akár kapcsolótáblával miként lehet leírni az elméletileg termékenként eltérő és akár végtelen számú tulajdonság létező kombinációit az egyes csoport elemeihez.
Mert most mi ezt egy generált kóddal tudtuk csak megoldani, ahol egymás után sorakoznak az adott termék egyéni tulajdonságai az alapján, hogy az adott termékhez mi van rendelve a tulajdonságtáblában.
Normalizálás
Nem követtem szóról-szóra az itt folyó társalgást, de valahogy az jött le, hogy ez vagy nem ismerős vagy valamiért nem akarsz foglalkozni vele.
Ahogy én kivettem a
A kérdezőnek: én netes cikkek mellett a Beginning Database Desing c. könyvet olvastam. Ebben szépen elmagyarázzák az alap koncepciókat. Erősen javaslom, hogy olvass bele, mielőtt továbbmész a jelenlegi vonalon. Ebben a témában angol forrást javaslok, mert amikkel magyar nyelven találkoztam, azokat nem igazán értettem, de ez lehet hogy az én személyes defektem.
Fordítva
Nem is az a fő probléma amit ti láttok, de valószínű az én hibám, hogy rosszul próbálom leírni, mert az alap problémára koncentrálva nem részleteztem ki minden.
Nálam sincsenek ugyanazok az adatok 50 helyen tárolva, csak az egyszerűség kedvéért nem nem írom le, hogy pl. a termékek képét, leírását, kategóriáját nem feltétlen a terméknél tárolom, hanem egy másik táblában, és akkor ezt már szinte olyan mintha ez lenne az itt emlegetett csoport tábla, stb...
Mert nem ez a problémám
Akkor kiragadom azt az utolsó hozzászólásból ami igazából a két rendszer méregfoga szerintem.
Úgy vettem észre hogy azzal nincs gond, hogy ha van az 1234 azonosítója termék akkor egy hozzá társított táblában meghatározom, hogy milyen spec tulajdonságai lehetnek (ami beszerzésileg külön fizikai terméket is jelent).
Azzal sincs talán gond, hogy ehhez jön egy újabb tábla amiben az adott (egy termékhez kötődő) tulajdonság lehetséges értékkészleteit tárolom. (Ez ugye ahhoz is kell, hogy pl. ezeket ki tudja választani az ügyfél.)
Azzal sincsen gond, hogy ha van egy termék, és annak egy tulajdonsága van, akkor egy szép kapcsolótáblával össze lehet kapcsolni a fizikai raktárkészlettel.
3 mező kell: termék_azon, tulajdonság_érték, fizikai_raktár_azon
(ez is csak most egy primitivizált leírása)
A problémám csak annyi, hogy így nem tudom megoldani, hogy mi van ha egy terméknek két tulajdonsága van...
Persze tudom a gyors választ:
4 mező kell: termék_azon, tulajdonság1_érték, tulajdonság2_érték, fizikai_raktár_azon
De ha ezt követném, akkor innentől nem lenne megállás. Amennyiben elvben végtelen ilyen tulajdonsága lehet egy terméknek akkor végtelen mezőre lenne szükség.
Tehát kéne egy bazi nagy kapcsolótábla, amibe csinálok 50 mezőt, és akkor azt mondom max. 50 tulajdonság lehet. ez ugye nem jó, mert az esetek 99.999%-kában teli lenne üres adatokkal.
Ezért vagyok kénytelen azt mondani, hogy a kapcsolótábla helyett egy mezőt használok amibe belekódolom az értékek sokaságát (pl. _ –sal elválasztva).
De ha jobban tetszik ezt a kapcsolótáblával is megtehetném:
4 mező kell: termék_azon, összes_tulajdonság_érték_egybe kódolva, fizikai_raktár_azon
Tehát arra adjatok instrukciót, hogy ezt hogy lehet megoldani kapcsolótáblával elegánsan.
Azt, hogy azt tudjam mondani:
- 1234 termék, ami 0.5 literes, és ráadásul barack ízű, és szénsavmentes, annak a raktári azonosítója X
- 1234 termék, ami 1 literes, és körte ízű, és buborékos, annak a raktári azonosítója Y
stb.
Előre is köszönöm a segítséget.
Egy tipp
Termék_azon | Raktár_azon | Tulajdonság_azon | Tulajdonság érték
1234 | 1234_X | 1 | 0,5
1234 | 1234_X | 2 | alam
1234 | 1234_X | 3 | szenszavas
1234 | 1234_Y | 1 | 1
1234 | 1234_Y | 2 | alam
1234 | 1234_Y | 3 | szenszavas
1234 | 1234_Z | 1 | 1
1234 | 1234_Z | 2 | korte
1234 | 1234_Z | 3 | szenszavas_mentes
Ez szerkezetileg jónak tűnik.
A gondom viszont ezzel, hogy a raktár_azon és a tulajdonság_azon párosa (web esetén még a termék_azon is kell hozza) ad meg egy tulajdonságértéket. Ami nem baj hogy egy termék kiírásakor (hogy tudjon választani az ügyfél) és a raktárkészletezőben is pont fordítva nyúl hozzá a rendszer az adatoknak. Aminek az eredménye, hogy egy csomó plusz művelet kell, hogy egyáltalán ki lehessen íratni az adatokat.
"A problémám csak annyi, hogy
Persze tudom a gyors választ:
4 mezo kell: termék_azon, tulajdonság1_érték, tulajdonság2_érték, fizikai_raktár_azon"
Nem ez a válasz, hanem hogy fizikai tulajdonság alapján normalizálod a táblát, és akkor a te hibás válaszodból adódó újabb problémák fel sem fognak merülni.
Tehát lehetoséget biztosítasz a usernek, hogy o hozza létre fizikai jellemzot, amikor új termék kerül a raktárkészletbe. Pl amikor beérkeznek a szemüvegek, akkor a user választhat a már meglévo kategóriákból. Ha még nem voltak szemüvegek, akkor a termékcsoportokhoz hozzáadja a szemüvegeket. Ekkor nyilván még a dioptria sem szerepelt a tulajdonságok között. Létrehozza ezt is. Viszont te ezt már táblaként hozod létre. Amikor új szemüveget hoznak, akkor a dioptria táblába foreign keyként bekerül a termékcsoport-részletezo táblából a termék id-je.
Amire figyelned kell fizikai jellemzok táblák létrehozásánál, hogy csak a termékcsoport-specifikus tulajdonságokat válogatod ide külön(dioptria, mubroki rücskössége etc...). Tehát ezeket a tulajdonságokat nem neked kell előre felvenni, hiszen ezeket a user fogja megadni, amikor új termékcsoportot vesz fel az adatbázisba. Azok a fizikai tulajdonságok pedig, amelyek minden egyes termékcsoport esetében fennállnak(kiterjedés, tömeg, szín) a termékcsoport-részletezo táblában maradnak. Ez azért fontos hogy vékony maradjon a tulajdonság táblád aminek nemsokára látni fogod az értelmét.
A raktári készletmennyiséget és a raktári számot a termékcsoport-részletezo táblában tárolod soronként. Itt a foreign key a termékcsoport tábla egyes sorainak id-ja lesz. Ugyanitt soronként tárolod a nem keresheto tulajdonságokat, ezek kb termékleírásként tudnak funkcionálni.
Utolsó mozzanatként létrehozol egy táblát, amiben a foreign keyek a termékcsoport ID-k lesznek, valamint lesz egy oszlop a kereshetővé tételezni kívánt fizikai tulajdonságok neveinek. Ha pl az egyik tulajdonság táblában 2 tulajdonság van, akkor 2 rekordod lesz ugyanazzal a foreign key-el. Ha egy másik tulajdonság táblában 3 van, akkor hozzájön még 3 és így tovább - most már látod miért kellett vékonyra hagyni a szeparált tulajdonságok tábláját. Ez azért lesz jó egyrészt mert a termékcsoportID ismeretében automatizálni tudod a lekérdezéseidet, másrészt megkönnyíted a terméket felvevő munkatárs dolgát amikor a <select>-ből csak a releváns tulajdonságokat ajánlod fel neki szerkesztésre és a tévedési lehetőségét is 0-ra redukálod, nem fog elmászni az adatod máshová.
Azt meg, hogy a joinolandó táblák nevét külön táblában tároljad, vagy pedig az utolsó mozzanatként létrehozott tábla érték-oszlopából mondjuk az első(de bárhányadik lehet) foreignID szerint releváns mező értékét használjad fel névként, benchmarkolással eldöntöd.
A fenti döntés függvényében tehát 4 vagy 5 táblára lesz szükséged:
1¤termékcsoport
2¤termékcsoport-részletező
3¤termékcsoportra jellemző kereshető fizikai tulajdonságok
4¤ a 3 as pontban szereplő tábla(táblák) oszlopnevei ömlesztve+t.cs. foreignkey
és az opcionális 5. tábla
A 3-as táblából sok lehet az árukészlet függvényében, meg hogy mennyire akarják über-kereshetővé tenni. De az is könnyen meglehet hogy bizonyos termékcsoportok azonos 3-as táblát fognak használni mert mondjuk csak a márkanevük lesz eltérő az ebből a szempontból lényeges tulajdonságaik megegyeznek. Teszem azt Tisza v Puma cipők vagy Coca v Pepsi termékek.
Aztán bejöhetnek még finomítások pl eldöntendő tulajdonságokat külön táblába teszed stb. De ezt már ki tudod találni ezek alapján amiket leírtam.
Ha ezt így megcsinálod, akkor nem lesz olyan problémád, mint amit leírtál, hogy akkor na hogyan is UPDATE eljünk bizonyos adatokat mert nem lesz kilométer hosszú attribútum-listád hozzáhegesztve a termékID-hez.
válasz
Ez szép és jó. Kb. meg is értettem. És tetszik is. De mint írtam itt nem a kereshetőség a probléma. Itt végig nem azon tulajdonságokról beszélek amikre keresni lehet meg nem lehet, hogy azokat hogy tároljuk.
Az hogy nálad vannak termékcsoportok az jó. Én ezt a részét nem firtattam, hogy milyen termékcsoportok vagy kategóriák vannak. (Ez természetes, főleg hogy a ropitól a vibrátorig bármi lehet a termék.)
De a te megoldásodból még mindig nem látom azt ami a probléma. Hogy ha lenne olyan csoportom, hogy gyógyszerek, üdítők, vibrátorok, édességek, stb…., akkor hogy lesz ebből az, hogy ha van egy XYZ üdítőm (üdítők csoport), ami a web áruháznak egy termék, az a raktárnak 10 féle legyen (10 raktár-azonosítóval).
Tehát amire idáig azt mondtuk hogy csoport, az a mi esetünkben nem úgymond kategóriát jelentett, hanem hogy az ugyanaz a XYZ ruha, 3 színben és 5 méretben van, ezért a raktár rendszerben annak 15 fizikai termékként kell szerepelnie. 15 egyéni raktárkóddal (de ez is csak akkor ha egyáltalán minden variáns létezik)… Tehát eddig arra mondtuk a csoportot, hogy meghatározzuk, hogy a 4000 rekord közül melyik az a 15 ami ugyanazt jelenti web áruház szempontjából.
Tehát nem a szépen kereshető tulajdonságok a problémám.
Hanem ha az admin felvesz egy adott terméket a raktárba (pl. egy XYZ színes fehérnemű), és ez van piros, kék és zöld színben és kékből csak S-es, a többiből meg S,M,L és SL-es létezik, akkor ennek mint fizikai terméknek a raktár szempontjából 9 raktárkódot kell kiosztani (9 rekord), mert a beszerzés, raktárnyilvántartás szerint ugye 9 különböző termék. A web áruházban viszont azt szeretnék kiírni, hogy létezik egy darab XYZ fehérnemű.
De azt annyira szabadon, hogy lehet hogy az admin a következő fehérneműjének a neve: ASD piros tanga. Ennek rögtön már csak mérete lesz, ami mondjuk csak L-es és XL-es lehet.
Ha ilyen szempontból értelmezném az általad írt csoportokat (összetartozó rektártermékek), akkor látható, hogy 200 terméknél már 200 tábla lesz.
(természetesen az admin dolgát meg lehet könnyíteni, hogy pl. a fehérneműnél ne ajánlja az űrtartalmat. De ha egy terméknél az kellene neki (szexi tanga, mely összehajtva vödörként is használható), akkor annál az egy terméknél igen is legyen űrtartalom is, mert a nagykerből (5, 10 és 12 literes méretben is) beszerezhető. De ne úgy, hogy ezért a többi fehérneműnél is megjelenjen az űrtartalom.)
"De a te megoldásodból még
De látszik csak nem értetted meg teljesen a leírásom alapján. Mert más absztrakciót veszel alapul mint én. De akkor megmutatom egy példával.
termékcsoport tábla:
termékcsoportID(PK)|megnevezés
1 Nike női tanga 2008/tavasz széria
2 Puma női tanga Takeitofffast széria
3 Persil mosópor
(látod az én termékcsoportjaim egészen specifikusak! ez okozta hogy nem értettél meg elsőre- ezzel kapcsolatban lesz egy külön pont (*) a végén.)
termékcsoport-részletező tábla :
termékid(PK)|termékcsoport(FK)|dimenzio|tömeg|jellemzes|szín|rak. kód|rakt. mennyiség
1 1 10*10*1 10 akármi blue TangaXY-1 69
2 1 10*10*1 10 akármi blue TangaXY-2 12
3 1 10*10*1 10 akármi dotted TangaXY-3 2
4 2 10*10*1 11 akármi zebra TangaXY-3 112
5 3 50*50*10 30 intelligens fehér Moso-1 20
tangák jellemzők tábla:
jellemzőkid(pk)|termék(FK)|méret
1 1 S
2 2 S
3 3 M
4 4 XL
Mosoporok jellemző tábla
jellemzőkid(pk)|termék(FK)|hány mosásra elég|szineset mos -e
1 5 13 1
Mint látod a t.cs részletező tábla lesz a raktárad.
"Ha ilyen szempontból értelmezném az általad írt csoportokat (összetartozó rektártermékek), akkor látható, hogy 200 terméknél már 200 tábla lesz."
A fenti példában látható (tanga bugyik)hogy az azonos jellegű termékek közös jellemző táblát használnak. Így közel sem fog a tábláid száma olyan gyorsan nőni mint a termékeid száma, hacsak nem mindenből egyfajtát akartok árulni.
A lényeg, hogy amikor a webshop kiírja a terméket, akkor a termékcsoportból írod ki a releváns találatokat. A választható opcióknál pedig a termékcsoport részletező tábla releváns találatait írod ki. Ami ugye egyben a raktárad is lesz.
Ami még fennakadást okozhatott :
"De azt annyira szabadon, hogy lehet hogy az admin a következő fehérneműjének a neve: ASD piros tanga. Ennek rögtön már csak mérete lesz, ami mondjuk csak L-es és XL-es lehet."
-Nem igaz hogy csak mérete lesz, a piros tangának ugyanúgy megvan a színe azért mert a nevébe is beleírtad a színt. Tehát itt a usernek be kell állítania a színt ugyanúgy. Az nem megy, hogy csinálok egy relációs adatbázist, felépítem a táblákat, és akkor randomra eldöntöm, hogy kitöltöm -e a mezőket, vagy mivel bal lábbal keltem fel, beleírok minden tulajdonságot a név mezőbe oszt csókolom. A relációs adatbázisban vannak megkötések amiket tisztázni kell, az úgy nem megy, hogy összevissza írogatok, aztán kereshető is legyen updatelhető is meg kávét is főzzön. Tehát a te általad említett példa esetében a piros tanga csak egy rekord lesz a nevétől függetlenül, a tulajdonságai meg a többi tangával megosztva fognak szerepelni a részletező táblában szintén rekordként. Tehát itt nem fog létrejönni új tábla azért mert a nevébe beleírtad hogy piros.
A terméktulajdonság allokációs táblát úgy veszem, hogy megértetted, mert nem kérdeztél rá külön.
Remélem sikerült érthetően bemutatni a dolgot. Nyilván ez csak egy minta amit neked testre kell még szabnod a felmerülő igényeket figyelembe véve, amit megtárgyaltok a megrendelővel.
"Tehát nem a szépen kereshető tulajdonságok a problémám."
Megnéztem volna, mire megírod az UPDATE-eket a te módszeredhez.
(*)
Természetesen a termékcsoportok esetén az elvonatkoztatási szintet is be lehet állítani úgy, hogy a fent bemutatott PK-FK párosítások alapján a termékcsoportok tábla fölé újabb táblákat teszel. Ezek szintén létrehozhatóak a user által de ezt már nem részletezem mert a logika ugyanaz mint az előbb csak itt 1-több kapcsolatokat hozol létre.
.
„Az nem megy, hogy csinálok egy relációs adatbázist, felépítem a táblákat, és akkor randomra eldöntöm, hogy kitöltöm -e a mezőket, vagy mivel bal lábbal keltem fel, beleírok minden tulajdonságot a név mezőbe oszt csókolom.” Sajna ez is de. :(
A piros színt azért írtam hogy szemléltethessem, hogy valahol nem lesz minden tulajdonság, mert látom hogy mik lesznek és miként akarnák kezelni. De lehet hogy nem azt jelenti, hogy az adott dolog a névbe kerül, hanem hogy nem jellemző minden esetben.
„Megnéztem volna, mire megírod az UPDATE-eket a te módszeredhez.” Rákeresek az egyéni raktár_azon-ra és UPDATE.
De félre a tréfát. A tulajdonságok tárolására annyi az eltérés, hogy te csoportokba külön táblába teszed őket mezőkbe, én pedig termékenként egy táblába egymás alá (de akár lehetne csoport is).
De azt a részt látom, hogy maga a raktári termékek ott vannak termékcsoport-részletező táblában csak úgy mint nálam. De mikor a webre teszem ki, akkor miből látom, hogy „termékcsoport-részletező tábla” mely termékkódjai takarják ugyanazt a terméket.
A te esetedben, az 1-4 ugyanaz a termék. De ha lenne egy ilyen sor is:
6 2 10*10*1 11 akármi lila TangaXY-3 122
akkor a 6-os is ugyanaz a termék még?
Lehet, hogy nem volt
Ja
Tehát a web áruház szempontjából fel tudunk venni minden termékhez egyéni tulajdonságokat (tulajdonság mátrixokat).
Akkor a két verziónk már nagyon hasonlít ha jól látom.
Mert az eredeti leíráshoz képest írtam, hogy akár az összetartozó elemeket ki lehetne tenni csoporttáblába ahogy itt írták mások is.
És később olyat is írtam, hogy az egy mezőben kódolt variációkat (pl. 1234_kek_XL) ki lehetne egy kapcsolótáblába tenni.
Csak míg te csoportonként optimalizált mezőszámú táblákat használsz, hogy úgy mint az eredeti variációban (1234_kek_XL) egy mozdulattal ki tudd olvasni a tulajdonság-mátrixot, addig én oszlopok helyett egy 3-4 oszlopos táblában tárolnám az összes értéket.
termékid(PK)|termékcsoport(FK)| tulajdonság | érték
1 | 1 | méret | S
1 | 1 | szin | KÉK
2 | 1 | méret | L
2 | 1 | szin | KÉK
3 | 1 | méret | S
3 | 1 | szin | PIROS
Természetesen hozzáteszem:
"termékcsoport(FK)"-ra igazából nincs is szükség nagyon
Illetve az egyszerűbb átláthatóság miatt írtam be a tulajdonságok úgy, hogy méret és szín. Élesben, azt ugye úgy illik, hogy ezek külön táblában vannak, és csak hivatkozunk rá.
Ennek csak annyi a hátránya, hogy míg te egy mozdulattal látod az egész mátrixot (szín és méter), addig én több sor kiolvasása után.
És ez volt ami annyira nem tetszett.
Kérlek erősíts meg jól látom –e?
Egy újjabb ötlet
Egyenlőre tekintsünk el attól, hogy létezhetnek termékcsoportok abban az értelemben mint kategória (műszaki cikk, élelmiszer, stb.). Ez csak a lényegről terelné el a figyelmet.
Lenne egy termékek tábla. Ez alkotná igazából a raktárkészletet.
raktar_id (PK) | csoport_id (FK)| raktári neve (ha szükségesnek tartjuk, hogy kezelés szempontjából az admin el tudja nevezni őket) | esetleg pár mező, mely minden termékre jellemző (reagenross lapján, most a példa kedvéért az állag) | mennyiség (ezt az egyszerűség kedvéért tettem most ide, de igazából ennek az adatnak meg a számlák és megrendelések táblából kellene következnie)
1 | 1 | XYZ TANGA kék S | szilárd | 69
2 | 1 | XYZ TANGA piros L | szilárd | 2 12
3 | 1 | XYZ TANGA piros XL | szilárd | 2
4 | 2 | XYZ TANGA zold M | szilárd | 112
5 | 3 | ASD intelligens fehér 2 kg| szilárd | 20
6 | 3 | ASD intelligens fehér 4 kg | szilárd | 30
7 | 4 | ASD intelligens színes 4 kg | szilárd | 220
Lenne egy tulajdonságtábla:
Ebbe nem termékenként lennének a tulajdonságok, újra és újra a tulajdonságok, hanem gyűjtőként. Tehát alap esetben egyszer létezik benne az, hogy szín, tömeg, felbontás, ruhatípus, stb.
A típus azt hivatott jelölni, hogy az adott tulajdonság egyáltalán egy változtatható érték, vagy mondjuk mint a szélesség egy szabadon beírható dolog, stb.
attr_id (PK) | Tulajdonság neve | Típusa
1 | Szín |Select
2 | Méret | Select
3 | ruhatípus | Select
4 | különleges jellemző | text
5 | súly | number
Ezek után lenne egy tábla, mely a választható tulajdonságok esetén a lehetséges értékeket határozza meg. (Text és number típusnál ilyenre nincs szükség.)
Ha az admin feladatát szeretnénk megkönnyíteni, akkor valahol lehet jelölni, hogy az egyes termékkategóriánként milyen érték a jellemzők. Tehát ha a ruhák miatt 200 féle színt veszünk fel, akkor a monitoroknál csak azokat ajánlja fel, amik ami a monitorokra jellemző.
Pl. az alapján hogy eddig milyen színeket vettek fel monitorokhoz, az alapján a rendszer összeállít egy listát és azt ajánlja fel. Ha nem találja az admin, akkor kérheti a teljes színkészletet. És ha ott sem találja, akkor felvehet egy újat. Így a monitoroknál addig nem lesz zebramintás, míg valamelyik monitor tényleg nem olyan.
value_id (PK) | Kategóriacsoport | attr_id (FK) | Megjelenő szöveg
1 | 1 | kék
2 | 1 | piros
3 | 1 | zöld
4 | 2 | S
5 | 2 | M
6 | 2 | L
7 | 2 | XL
8 | 2 | XXL
9 | 3 | színes
10 | 3 | fehér
A kapcsoló tábla pedig így nézne ki
A Primer azt jelentené, hogy az adott tulajdonság raktározási szempontból fontos –e. Tehát alkot –e egyéni raktári készletet. Igazából ez csak tájékoztató jellegű, de lehet még jó valamire.
A dimenzió az adott tulajdonság mértékegységét jelöli. Bár most ez egy meírható mező, de akár ez is lehet olyan, hogy adott tulajdonságra jellemző listából lehetne választani. Ez lehet külön táblában is, és arra hivatkozni, de ha nincs nagy jelentősége, akkor akár ezt felsorolásszerűen egy mezőben tárolom, és majd a PHP-val feldolgozom.
raktar_id (FK) | attr_id (FK) | value | Primer | Dimenzio
1 | 1 | 1 | true | (üres)
1 | 2 | 4 | rue | (üres)
2 | 1 | 2 |true |(üres)
2 | 2 | 6 | rue | (üres)
3 | 1 | 2 |true |(üres)
3 | 2 | 7 | rue | (üres)
4 | 1 | 3 |true |(üres)
4 | 2 | 5 | true | (üres)
5 | 3 | 10 |false |(üres)
5 | 4| inteligens |false |(üres)
5 | 5 | 2 | true | kg)
6 | 3 | 10 |false |(üres)
6 | 4| inteligens |false |(üres)
6 | 5 | 4 | true | kg)
7 | 3 | 9 |false |(üres)
7 | 4| inteligens |false |(üres)
7 | 5 | 4 | true | kg)
Igaz hogy ez esetben a tulajdonságok nem egy rekordban vannak, de mivel ezek akkor kellenek mikor egy termék, vagy összetartozó termékek vannak listázva, ezért könnyen lekérdezhetőek egy mozdulattal.
A kereshetőség is megvan, mert innentől nem termékenként van újra és újra felvéve pl. a szín, hanem minden termékhez ugyanaz az egy tulajdonság van hozzárendelve. Így elméletileg ha azt mondom, hogy valami feketét keresek, akkor megkaphatom a fekete a bugyit, és a fekete keretű monitort is.
Ha bevezetjük, hogy az összetartozó termékek (web áruház szempontjából egy termékek gyűjtője) kitesszük egy külön táblába, akkor tovább optimalizálhatjuk a tulajdonság dolgot. (hogy ugyanazt a jellemző tulajdonságot ne tároljuk le többször. Pl. 5-4 , 6-4 és 7-4)
Ekkor a raktárkészlet szempontjából fontos adatok kerülnek csak a kapcsolótáblába (Primer=true), és mondjuk egy másik táblába a termékcsoportra (web áruház szempontjából egy termékek gyűjtője) jellemző kapcsolótáblába kerülnének a másodlagos tulajdonságok ugyanúgy. Csak ez esetben a „raktar_id (FK)” helyett „csoport_id (FK)” lenne.
(de egyben is tartható, de akkor a Primer azt mondja meg, hogy az a raktári termékre jellemző vagy a web áruházi termékcsoportra jellemző. Tehát milyen érték van az első mezőben. )
A kérdésem az lenne. Hogy mennyire tűnik jó megoldásnak?
Ui.: A web áruház szempontjából összetartozó adatokat tároló táblát nem írtam le, mert talán az egyértelműen következik. Bár kérdés, hogy mennyire nagyon szükséges a netes gyűjtőnév miatt egy külön tábla. Jó tudom a normalizálás miatt, de akkor is….