Eltérő termékek egységes kezelése adatbázisban
Sziasztok!
A segítségeteket szeretném kérni.
Egy olyan adatbázist kellene felépítenem, melyben teljesen eltérő termékeket tudok tárolni.
Olyan mint egy webshop, csak itt nincs egy megfogható termékcsoport.
Pl. tartalmazhatja egy CPU-t, egy házat, egy autót, egy mosógépet, egy üdülést, stb.
Ezeknek a termékeknek ugye igen csak eltérő tulajdonságai vannak, amiket tárolni is szeretnék.
A legfontosabb, hogy gyors legyen a rendszer mind keresésre, mind pedig tallózásra.
Ha pl. beírom, hogy piros, akkor szeretném látni a piros mobiltelefontól a piros autón keresztül a piros sportdzsekin át az összes olyan terméket, ami piros, viszont az is fontos lenne, hogy a termék neve alatt szerepeljen az aktuális termékcsoportra jellemző összes fő tulajdonság úgy, hogy az nem újabb lassú lekérdezések árán legyen csak lehetséges.
Pl.
Nokia 3510i
kártya független
MMS képes
WAP képes
FIAT UNO
1998-as évjárat
300 m3
4 ütemű
ADIDAS dzseki
újszerű állapotú
piros
1.
Alap esetben az lenne a legegyszerűbb, ha csinálnák egy 500 mezős táblát, 380 index-el, és ebben felvennék minden lehetséges tulajdonságot az órajeltől, az alapterületen át a végsebességig. Egy admin táblában meghatároznám, hogy az egyes termékkörök esetén mit kell kitölteni, és a többi tulajdonság NULL-t venne fel.
Ugye ekkor egy keresésnél minden információ rendelkezésre áll, viszont nem feltétlen a legszerencsésebb választás.
2.
A másik lehetőség, hogy az alap tulajdonságokat veszem csak fel (neve, kategória, ára, stb.) és a kiegészítő tulajdonságokat egy másik táblába helyezem el, ahol szerepelne a termék ID-ja a tulajdonság azonosítója (3. tábla) és az érték. Itt mivel igencsak eltérő értékek lehetnek (szám, szöveg, stb.), ezért csak szövegesen tudnám ábrázolni az egyes értékeket ami lassítaná a keresést, illetve ha sok tulajdonságok szeretnék egyszerre figyelni, akkor sok JOIN vagy SELECT lenne.
Mit ajánlanátok?
Előre is köszönöm a segítséget.
Üdv:
Zoli
■ A segítségeteket szeretném kérni.
Egy olyan adatbázist kellene felépítenem, melyben teljesen eltérő termékeket tudok tárolni.
Olyan mint egy webshop, csak itt nincs egy megfogható termékcsoport.
Pl. tartalmazhatja egy CPU-t, egy házat, egy autót, egy mosógépet, egy üdülést, stb.
Ezeknek a termékeknek ugye igen csak eltérő tulajdonságai vannak, amiket tárolni is szeretnék.
A legfontosabb, hogy gyors legyen a rendszer mind keresésre, mind pedig tallózásra.
Ha pl. beírom, hogy piros, akkor szeretném látni a piros mobiltelefontól a piros autón keresztül a piros sportdzsekin át az összes olyan terméket, ami piros, viszont az is fontos lenne, hogy a termék neve alatt szerepeljen az aktuális termékcsoportra jellemző összes fő tulajdonság úgy, hogy az nem újabb lassú lekérdezések árán legyen csak lehetséges.
Pl.
Nokia 3510i
kártya független
MMS képes
WAP képes
FIAT UNO
1998-as évjárat
300 m3
4 ütemű
ADIDAS dzseki
újszerű állapotú
piros
1.
Alap esetben az lenne a legegyszerűbb, ha csinálnák egy 500 mezős táblát, 380 index-el, és ebben felvennék minden lehetséges tulajdonságot az órajeltől, az alapterületen át a végsebességig. Egy admin táblában meghatároznám, hogy az egyes termékkörök esetén mit kell kitölteni, és a többi tulajdonság NULL-t venne fel.
Ugye ekkor egy keresésnél minden információ rendelkezésre áll, viszont nem feltétlen a legszerencsésebb választás.
2.
A másik lehetőség, hogy az alap tulajdonságokat veszem csak fel (neve, kategória, ára, stb.) és a kiegészítő tulajdonságokat egy másik táblába helyezem el, ahol szerepelne a termék ID-ja a tulajdonság azonosítója (3. tábla) és az érték. Itt mivel igencsak eltérő értékek lehetnek (szám, szöveg, stb.), ezért csak szövegesen tudnám ábrázolni az egyes értékeket ami lassítaná a keresést, illetve ha sok tulajdonságok szeretnék egyszerre figyelni, akkor sok JOIN vagy SELECT lenne.
Mit ajánlanátok?
Előre is köszönöm a segítséget.
Üdv:
Zoli
Embereknek készül?
Semmiképp se csinálj 500 mezős táblát.
Döntsd el pontosan, hogy mit akarsz, mit akar majd a user, és aszerint normalizáld a tábláidat!
Válasz
Ez csak egy példa volt, de nem feltétlenül a legszerencsésebb ezek szerint.
A lényeg, hogy az egyes kategóriákban (ingatlanok, gépkocsik, számítógép alkatrészek, üdülések, stb.) különböző típusú tulajdonságokat kellene tudnom kezelni.
Protezis
Egyre gondoltunk. Pont most írtam ugyanezt csak másik példával.
Viszont jó lenne, ha a termékek lekérdezéskor egyben láthatnám a termékek mellett a termekek_tulajdonsagok összekapcsoló táblában lévő összes – az adott termékhez tartozó - tulajdonságot, ami ugye ott külön soronként szerepel.
Vbence
„termékeket "repülő" tulajdonságokkal” Ez mit jelent nálad? Mi az, hogy „repülő”?
Ha jól értem te azt javaslod, hogy legyenek úgy tárolva az adatok mint ahogy Protezis írta, de készüljön belőle egy globális nagy tábla is a listázás és keresés miatt.
Ezt mikor gyártanád? Amikor egy új rekord kerül a rendszerbe, illetve akkor bővítenéd, ha egy új tulajdonság kerülne felvételre?
Üdv:
Zoli
Nem...
A repülő tulajdonságoknak azokat nevezem, amik nem szerepelnek minden egyes elemben. (A második megoldásban ezek kerülnek a külön táblába.)
Ahogy en csinaltam
- termekek (id, nev, leiras, ...)
- tulajdonsagok (id, nev)
- termekek_tulajdonsagok (id, termek_id, tulajdonsag_id, ertek)
Pl.:
termek:
- 1, Nokia 3510i, jo kis telefon
- 2, ADIDAS dzseki, jo kis dzseki
tulajdonsag:
- 1, kártya független
- 2, MMS képes
- 3, WAP képes
- 4, szin
- 5, allapot
termekek_tulajdonsagok:
- 1, 1, 1, igen
- 2, 1, 2, igen
- 3, 1, 3, igen
- 4, 2, 4, piros
- 5, 2, 5, ujszeru
Ebbe is vihetsz be termekcsoportokat, null-okkal viszont nem kell feltoltened semmit.
Termesztesen a tulajdonsagokat fel kell venni (ez is konnyen megvalosithato), ez azonban kesobb egyre ritkabban jelent problemat.
Egytábla
Én az elsőt választanám. Ha tényleg listáznod kell termékeket "repülő" tulajdonságokkal, akkor egyértelműen ez lesz a legjobb megközelítés. Hátránya az, hogy nem esztétikus, és "talán nagyobb".
Overhead? Egyrészt a vinyó hely ára a nullához konvergál. Másrészt a sok fölösleges, NULL tartalmú mező átvitele a DB és a PHP között nem hiszem, hogy sok helyet foglal a socketben. Megjegyzem, ha már szűkítve van termékcsoportra (pl telefon), ahogy az esetek 90%ában lesz is, akkor a lekérdezésbe beleszőheted, hogy a fölösleges mezők ne jöjjenek át.
Ha pedig belegondolunk abba, hogy a tulajdonságok nagy része gyakorlatilag boolean lesz (MMS van/nincs, EDGE van/nincs), így a fölösleges mezők is, egy tinyint pedig lényelgesen kevesebb helyet foglal, mint egy numerikus ID mező (mondjuk egy 32 bites), és egy varchar mező, amit a lehető leghosszabbra kell vegyél beleférjen az az egy-két eset is, amikor litániákat kell írni bele.
Szóval egyértelműen és kategórikusan a mamuttáblát választom. Ha zavar, hogy nem esztétikus, használd az adminisztrációhoz a "szép" megoldást a repülő mezőkkel, és ebből mintegy cache-ként gyártsd le a produkciós környezetben működő nagytáblát.
Egy kis megjegyzés: ne használj text mezőt, amilyen tulajdonság nem fér bele 250 karakterbe, azt amúgy is jobb többfele választani. Egy nem rögzített hosszúságú mező, mint a text eléggé be tudja lassítani a táblát.
Nem látom át, mi a koncepció
Válasz
Ebből adódóan sok féle termék és szolgáltatás szerepel rajta egyidejűleg.
Ha valaki keres egy terméket, szolgáltatást, azt nekem az összes - esetleg szűrés esetén (pl. valaki csak az ingatlan kategóriában keres) - rekord között figyelnem kell.
Természetesen nem csak a termék nevére, és árára szeretnék keresni, hanem bármely tulajdonságra is.
(természetesen itt is jelzem, hogy az szabályozva lesz azért, hogy pl. a videokártyákat nem lehet majd szín szerint keresni).
Ha csak normál keresésről lenne szó, akkor még talán nem is lenne annyira nagy a problémám.
Viszont az elképzelésem az, hogy egy-egy terméket több irányból is meg lehessen találni, kvázi nem előre beégetett kategórialista legyen csak.
Pl.: egy bababútort meg lehessen találni a
- bútor -> bababútorok
és a
- baba és gyerekholmik -> bútorok
struktúrán is. Természetesen most nem az adott példánál ragadjunk le, mert most ebbe is biztos bele lehet kötni.
A lényeg, hogy nekem ehhez szükségem van, hogy az adott szinten egyben lássam, hogy milyen tulajdonságokkal rendelkeznek az adott termékek.
Üdv:
Zoli
Szerintem...
Egyrészt jo hogy egy táblában "kéznél van" minden,de a példánál maradva,egy 500 mezös táblánál,nem hiszem hogy hatékonyabban lehetne keresni a "piros" tulajdonságra,amely az 500 mezö közül bármelyikben lehet,(pláne ha több tulajdonságra keresel),mint egy több táblás lekérdezésnél.
Még akkor is ha mondjuk a tulajdonságok táblában van 10-15 varchar esetleg text mezö.
Ráadásul a megjelenités sem egyszerübb semmivel,hiszen nem ugyanazok a tulajdonságai vannak két különbözö kategóriának,és nem ugyanannak a tulajdonságnak az értéke lesz a "piros",egy másik termékkategoriában,amely szintén a találatok között fog szerepelni,hiába hogy egy táblábol származik az összes találat.
Persze,hacsak nem egy a táblához hasonlo x száz oszlopos táblázatban iratod ki az adatokat:D
---------
Én még egy olyan megoldást tudnék elképzelni(ami talán legközelebb áll,az egy táblás megoldáshoz),hogy meghatározod a tulajdonságok maximális számát ami bármely termékkategoriában megadható,(ami esetleg nem fér ebbe bele,az megadható egy általános "Leirás" mezöben),és annyi oszlopa lenne a táblának; a tábla oszlopai/mezöi csak egy általános nevet kapnak(pl.:ertek1,ertek2,ertekx),és az adott termékkategoriához tartozó tulajdonságok nevei,egy másik táblában(vagy akár fájlban) lesznek definiálva,igy max 2 tábla kell.
Persze ennek a megoldásnak is vannak korlátai,amik a késöbbi fejlesztés során hátrányt jelenthetnek...
Válasz
Természetesen ha lehet, nem egy táblában szeretném tárolni az adatokat, és természetesen nem minden mezőben ugyanaz lenne leírva. Pl. a "pirosat" a szín mezőben keresném.
Ezen kívül nem minden adatra van szükségem mindig, de hogy melyikre az változó.
Ezért kérem a segítségeteket.
Pl.:
Ha azt válassza valaki, hogy babacuccok, akkor nem írhatom egy bútorra ugyanazt, mint egy zoknira (13-mas mértet fiú).
Természetesen azt, hogy mire van szükségem, azt az adott termék besorolása dönti el.
Sajnos kicsit nehéz leírni mit szeretnék.
Ha valaki a "babacuccok -> fiú" között válogat akkor nekem bútorok azon termékeket kell kikeresnem amiknek a tulajdonságai között szerepel, hogy babacucc és azt, hogy fiú. Ez ezt jelenti, hogy a fiú pelenkától (ha van ilyen) a fiú gyerekszobabútorig minden terméket meg kell jelenítenem.
Ha ez a két tulajdonság mind fő tulajdonság szerepelhetne a terméket tartalmazó táblában, akkor egyszerűen ki tudnám olvasni. De ezt ugye nem akarjuk, mert akkor egy hatalmas táblát kapnánk, mert ezen kívül még nagyon sok féle tulajdonság létezik.
Ha külön táblában vannak a tulajdonságok, akkor ki kell válogatnom a babacucc tulajdonságú termékeket amin mondjuk 10.000 db, majd megnézni ezek közül hogy melyik volt ezek közül fiú.
Ha a két táblát JOIN-nal kötöm össze, akkor meg fogom kapni azt, hogy van olyan termék ami babacucc és van olyan ami fiuknak való. Ezek után nekem kell kiválogatnom azt, hogy melyek amik minden tulajdonságnak megfelelnek. Ha még a bútoroknál a méretet, a pelenkánál a nedvszívóságot is ki szeretném írni, akkor az még egy pár JOIN lenne.
Mint említettem nekem "Protezis" megoldása nagyon jó lenne, hisz én is eljutottam eddig, viszont hogyan tudnám úgy összejoinolni a két táblát, hogy a "termekek_tulajdonsagok" táblában lévő étékek mintha mezők jelenjenek meg és így normálisan szűrhetők lennének.
Üdv:
Zoli
Erre gondolsz?
ha esetleg ez...
Válasz
Ez nagyon jó.
Viszont az lenne a kérdésem, hogy ez hogyan működik mondjuk 2 vagy 3 szűrt tulajdonság esetén?
Ezek után nekem kell összemolyolnom, hogy melyek amik mindkettőnek megfelelnek, vagy van rá szintén valami jó megoldás?
Most így elsőre arra gondoltam, hogy megszámolom hányszor szerepel az adott termék, és összevetem azzal, hogy hány tulajdonságra szeretnék szűrni.
Így megkaphatnám, hogy egy adott termék minden kritériumnak megfelel -e.
Valahogy így:
Az SQL-el csak annyi bajom van, hogy azon tulajdonságok esetén ahol nem szeretnék szűrni, hanem csak szükségem van egy adott tulajdonságra, ott ezt hogyan tudom megcsinálni.
Üdv:
Zoli
Nem tudom, van -e jobb
Kivancsi lennek egy jobb megoldasra...
Ha ezeket a termekeket akarod kilistazni (tulajdonsagaikkal egyutt), akkor a fenti lekerdezessel megkapod a megfelelo termekeket, es a korabbi (altalam javasolt) termeklekero query-nek a vegere ezt irod:
WHERE ter.id IN (ide jon az elobbi select ugy, hogy csak az id-ket kered le)
Válasz
Tehát kicsit leredukálva a jelenlegi SQL:
Addig míg kapunk egy jobb meg megoldást add lenne egy mellékel kérdésem:
A "termekektulajdonsagok" táblában hogyan tudok különböző típusú adatokat rögzíteni, hogy az jól indexelhető, és jól szűrhető legyen (pl. szűrés CPU sebességre: 1000-3000GHZ)?
Pl. int, float, bool, enum, text, stb.
Újabb táblákat vonnál be erre, vagy a 'termekektulajdonsagok' táblát különböző típus mezőkkel egészítenéd ki (int, float, text, stb.). Az értéket mindig a megfelelő mezőbe írnád. Az, hogy melyik tulajdonság esetén melyiket kell alkalmazni, azt pedig a 'tulajdonság' tábla egy újabb mezője határozná meg.
Üdv:
Zoli
Ez engem is erdekelne
Concat
Ezzel tudok létrehozni új mezőket és értékeket is beletenni.
Már csak azt kellene elérni, hogy a termékek egyes tulajdonságai mint egy-egy alias-al létrejöjjenek.
Csak még nem tudom hogy csináljam...
Szerkesztve:
Bocs. Most ökörséget írtam azt hiszem. A mezőt az 'AS' hozza létre.. ;)
Üdv:
Zoli
Egy újjabb ötlet
Kollegám a tulajdonságok mezőbe való összefoglalásával próbálkozik.
Elég ígéretesen indul.
1. valahogy úgy group by-olni az eredményeket, hogy az értékkel rendelkezők szerepeljenek csak egy sorban.
2. megoldani, hogy a mezőlétrehozás automatikus legyen és nem manuális
Üdv:
Zoli
Újjabb kisérlet
Köszönet Imrének.
Igaz még mindig meg kell adni, hogy milyen tulajdonságokra van szükségem, és nem adja vissza az őszeset amit a találatok adnak, de már szépen mezőkké fűzi össze a tulajdonságokat.
Üdv:
Zoli
"This is madness!"
Tag-ek
Címkézés + 1
???
Most akkor ti mit is ajánlotok?
Bocs az érthetetlenségemért...
Üdv:
Zoli
tagek címkék és egyébb állatfajták
tag {id int, word varchar}
termek {id int, ...}
termek_tag {termek int, tag int}
Magyarul van egy szótártáblád a témákkal (cimkékkel), és van egy kapcsolótáblád, ami ezta termékekre aggatja. Egy cimke természetesen csak egyszer szerepel (a tag táblában), az összekapcsolást ("sok a sokhoz" kapcsolat) a termek_tag végzi. (persze olyan elnevezési konvenciókal, amilyet szeretsz).
Kérdés
Viszont ennál a módszernél is lenne kérdésem.
1. a cimkéket biztos, hogy csoportosítani kell tudnom. Pl. ha színre szeretnék szürni, akkor tudnom kell melyek a cimkék amik színt fejeznek ki.
De ezt még ki is sakkozom talán.
2. mi van azokkal a tulajdonságokkal ami nem igen és nem tipusúak? Gondolok ist mondjuk méret, súj, órajel, stb. Ilyenkor felveszem a 20MHZ , 21MHZ , 22MHZ , 23MHZ , 24MHZ , 25MHZ ..... a 10mm, 11mm, 12mm, stb értékeket külön?
Üdv:
Zoli
tag vs keresés
Tulajdonság értékek
Lenne közben egy újabb kérdésem.
Hogy érdemes az egyes tulajdonságok lehetséges értékeit tárolni.
Ez pl. a termék rögzítéshez és a kereséshez lényeges.
Az én esetemben ettől bővebb az összefüggés (pl. egy gyártó típus egy PC alkatrésznél más, mint egy autó esetén, tehát kategóriánként más lehet az értéktartomány), viszont most leegyszerűsítem az egészet az adott problémára.
tulajdonsag:
- 1, kártya független
- 2, MMS képes
- 3, WAP képes
- 4, szin
tulajdonsag_etrekei:
- 1, 0, nem
- 1, 1, igen
- 1, 2, nincs megadva
- 2, 0, nem
- 2, 1, igen
- 2, 2, nincs megadva
- 3, 0, nem
- 3, 1, igen
- 3, 2, nincs megadva
- 4, 0, nincs megadva
- 4, 1, piros
- 4, 2, zöld
- 4, 3, sárga
- 4, 4, kék
- 4, 5, narancs
- 4, 6, lila
- 4, 7, fehér
- 4, 8, fekete
Ez így jó is lenne.
Viszont ugye nem csak ilyen típusú értékek lehetnek.
Pl. egy súly, egy órajel (ahol van min. és max. érték), vagy szöveges tulajdonság esetén, hogyan lehet ezt szépen tárolni ahol mondjuk a min. és max. szöveghossz van megadva.
Üdv:
Zoli
Virtuális mezők
Tehát létre kell hoznod egy módszert, ahogy ezeknek a mezőknek a metaadatait tárolod, és generálod belőle az adminisztrációs formokat. A produkciós környezetben viszont használhatsz egy "lerenderelt" változatot, ahol minden varcharként tárolódik.
???
Bocsi az újabb értetlenkedésemért, de ezt nem igazán sikerült megértenem mit is mondasz...
Tudnál segíteni a dekódolásában? ;)
Köszi.
Üdv:
Zoli
ok
A kész értékeket tárolhatod varcharként, úgyhogy az éles oldalon (az egyes lekérdezésekben) nem lesz feltétlenül szükséged erre a programrészre.
Ilyesmi?
tulajdonsag:
ID, nev, Type, MinValue, MaxValue, MinLong, MaxLong, Mertekegyseg
- 1, kártya független, set, NULL, NULL, NULL, NULL,
- 2, MMS képes, set, NULL, NULL, NULL, NULL,
- 3, WAP képes, set, NULL, NULL, NULL, NULL,
- 4, Szin, set, NULL, NULL, NULL, NULL,
- 5, Súly, doubel, 0, 12.5, NULL, NULL, kg
- 6, email, text, NULL, NULL, 50, 200,
tulajdonsag_etrekei:
- 1, 0, nem
- 1, 1, igen
- 1, 2, nincs megadva
- 2, 0, nem
- 2, 1, igen
- 2, 2, nincs megadva
- 3, 0, nem
- 3, 1, igen
- 3, 2, nincs megadva
- 4, 0, nincs megadva
- 4, 1, piros
- 4, 2, zöld
- 4, 3, sárga
- 4, 4, kék
- 4, 5, narancs
- 4, 6, lila
- 4, 7, fehér
- 4, 8, fekete
igen
;)
Ennek örülök.
Akkor lenne egy újabb még ide kapcsolódó kérdésem.
Már tudok szűrni, meg tudom határozni az értéktartományokat.
A kérdésem, hogy egy konkrét terméke esetén hogyan tudom tárolni az eltérő típusú tulajdonságokat?
Alaphelyzetben ez volt.
termekek_tulajdonsagok:
id, termék, ertek
- 1, 1, 1, igen
- 2, 1, 2, igen
- 3, 1, 3, igen
- 4, 2, 4, piros
- 5, 2, 5, ujszeru
Ha az értéket szám típusnak veszem, akkor mondjuk le tudom tárolni mondjuk egy CPU órajelét.
Ha SET típusról van szó, akkor szintén le tudom tárolni a szín sorszámát.
A kérdés, hogy egy szöveges értéket hogy tároljak, vagy egy dátumot, stb.?
Üdv:
Zoli
Új megközelítés
1. Mi a véleményetek róla?
2. Meg lehet csinálni, mert nekem hibával eldobja az SQL
Az új megközelítés szintén abból indul ki, hogy vannak a termékek tábla, és vannak benne alap tulajdonságok (id, név, ár, stb.)
Viszont ez a tábla tartalmazna egy olyan mezőt, mely egy hivatkozást tartalmazna egy tulajdonságtáblára.
Az lenne benne, hogy mely tulajdonságtábla kapcsolódik az adott termékhez.
Ez alapján külön el lehet szépen készíteni külön-külön a járművek, telefonok, ingatlanok, stb. tulajdonságait tartalmazó táblákat. Itt megoldódna a típus probléma és egy sor más is.
Lehet fordítva kellene nekiindulni. A tulajdonságoktól a termék felé.
Előre is köszönöm a segítségeket.
Üdv:
Zoli
Nem szép
1. Ha új termék típus kerül a rendszerbe, új táblát kell létrehozni és a kódhoz is hozzá kell nyúlni az új tábla szerkezetének megfelelő lekérdezések legyártásához (vagy valami ügyes ini/xml file-t kell mellékelned ami alapján automatizálod ezt a lépést, esetleg adatszótárazod a táblát és röptiben kéred le a tábla szerkezetét ami alapján majd dolgozol...
2. Annyiféle szűrő kell, ahányféle tulajdonság táblád van (hiszen mindegyik más szerkezetű)
3. Több lépésben kell a lekérdezéseket legyártanod: elsőként lekérdezed a termékhez tartozó kapocsolódó tábla nevét és ezzel az információval a kezedben kell legyártanod az összekapcsolt lekérdezés(eke)t
Mindenképpen a termékek, tulajdonságok és termék_tulajdonságok kapcsolótábla vonalon maradnék.
Válasz.
Mindennek meg van előnye és hátránya.
1. "új termék típus kerül a rendszerbe, új táblát kell létrehozni" mivel ez ritkán fordul elő, ezért ez még nem lenne gond.
2. Igen. Tudni kell, hogy egy-egy kategória milyen tulajdonságokat tartalmaz, ha nem lehet valahogy automatizálni.
3. Ez is igaz. Először meg kell nézni, hogy mely tulajdonság táblákat kell JOIN-olni(ha lehet kategóriára szűrni, akkor csak egy részét, ha nem, akkor az összest), majd ezek alapján létrehozni a select-et. Feltéve, hogy nem lehet megoldani automatikusan. (ez nem ment nekem)
Viszont előnye, hogy az értékek tárolása így egyszerű. Olyan típusú mezőket hozok létre ami éppen kell.
Persze közben találtam egy olyan bajt is ezzel, hogy ha két tulajdonságtáblában is szerepel olyan hogy "szin", akkor JOIN esetén két külön oszlopban is megjelenhetnek az értékek.
Nem tudom, hogy lehet -e kérni, hogy ezek össze legyenek vonva, vagy az, hogy ha azt keresem, akkor azt mindkét "szin" mezőben keresse, vagy csak úgy, hogy egy OR-al külön-külön le kell kérdeznem.
Viszont ha hagyjuk ezt a módszert, és visszatérünk a kapcsolótáblás megoldásra, akkor még mindig kérdés, hogy a termékekhez hogyan tudom tárolni a különböző típusú értékeket (int, double, date, text, stb.).
Mivel már így is elég sok összefüggés van, így jó lenne mennél egyszerűbben, úgy, hogy tényleg jól kezelhetően és gyorsan lehessen kezelni.
Előre is köszönök minden építő segítséget, gondolatot.
Üdv:
Zoli
Adat modell
nem értek egyet. Ha van kismillió tulajdonság táblád kismillió féle szerkezetben az nem jó adatmodell. Meg kell keresni a tulajdonságok legkisebb közös halmazát, és azt kell leírni a modellel. Jelen esetben ez annyi, hogy vannak termékeid amelyekhez 1 vagy több tulajdonság tartozik, a tulajdonságoknak van neve, típusa és értéke. A terméknek még vannak egyéb jellemzői (pl. egy vagy több tag tartozhat hozzá, vagy 1 vagy több kategóriában lehet stb). Ez a modell egy kellően elvont leírása a tárolni kívánt adataidnak, tetszőlegesen bővíthető anélkül, hogy hozzá kéne nyúlnod a táblaszerkezethez.
Az értékek tárolása szerintem sokkal egyszerűbb _egy_ olyan táblában aminek a szerkezete fix mint 15 táblában amiknek a szerekezete eltér...
Egy lehetséges megoldás, hogy leszűkíted a lehetséges típusok körét: szám, szöveg, időbélyeg
Mindent szöveg mezőben tárolsz és a tulajdonság típusa alapján konvertálsz ha kell.
Vagy a termék_tulajdonságok táblában lehet 3 meződ: érték_szám, érték_szöveg és érték_datum a megfelelő sql típussal (értelemszerűen mindegyikből a leghosszabb, hogy beleférjen minden).
üdv,
Zila
Így?
Tehát:
termekek_tulajdonsagok:
id, term_id, tul_id, value_number, value_text, value_time
- 1, 1, 1, 2, NULL, NULL
- 2, 1, 2, 2, NULL, NULL
- 3, 1, 3, 2, NULL, NULL
- 3, 1, 9, NULL, 'kis karccolás az oldalán', NULL
- 3, 1, 9, 2.4, NULL, NULL
- 4, 2, 4, 4, NULL, NULL
- 5, 2, 5, NULL, NULL, '2007-11-15 10:12:43'
Tehát tudnom kell a tulajdonság típusát, és a SELECT-ben akkor a mindig a megfelelő tagot kell beírnom.
Tehát ennek az értékét helyetesítse be....
Üdv:
Zoli
valahogy így
De ha a második akkor valahogy így:
koncepcionális problémát érzékelek
Mit szeretnél csinálni?
- Szabad szavas keresőt hozzá (a'la gugli)?
- Vagy bepipálható, részletes-keresés őskőkorszaki keresőform-szörnyeteget?
Én javallom az előbbit. Nem kell ezt túlspilázni. Írja be a júzer, hogy mit szeretne látni, te meg a kapcsolótáblán keresztül kiköpöd neki az eredményt. Arról nem is beszélve, hogy könnyedén lehet "ezekre kerestek a legtöbben" featurát csinálni.
Plusz egy vote a tag-tábla-kapcsolótábla-terméktábla hármasra.
Ja, és ne csoportosítsd a tag-eket típus szerint, mert nincs értelme. Azaz, kit érdekel, hogy a piros tag szín? Senkit. A júzer tudja, a rendszerednek meg irreleváns.
Válasz
Ez nem azért készül, hogy valaki tök hülye dolgokra tudjon rákeresni egy bazi nagy nagy keresőben.
Azért van szükségem a tetszőleges keresésre, hogy én tudjak szűrni a rendszeren velük tetszőleges dologra, ami bármikor változhat. Tehát ne legyen bebetonozva a rendszer.
A koncepció az, hogy az egyes termékek tárolása a rendszerben egy bizonyos struktúra alapján lennének elmentve.( kategória, alkatagorai, termékcsoportra jellemző egyéni tulajdonságokkal. [pl. épületnél a telek méret van, autónál futott kilométer, stb.])
Viszont az ügyfelek nem ezt az előre bebetonozott struktúrát látnák, hanem egy olyat, ami különböző irányokból meg tudja közelíteni a termékeket.
Olyan mintha lenne egy másik kategória struktúra az ügyfeleknek is, ami sok esetben ugyanazt a termékcsoportot fedi le bent.
Tehát nem a felhasználónak kell alkalmazkodni a mi struktúránkhoz, hanem min igazodunk a lehetséges elvárásokhoz. (Ugye ez alap helyzetben fel van töltve lehetséges csomópontokkal, viszont ezt bár mikor rugalmasan kell tudnom bővítenem.)
Minden, az ügyfelek által látott struktúraelem egy szűrő hivatkozást rejt magában.
Ez határozza meg, hogy az adott menüpont milyen termékeket jelenítsen meg.
Talán példával érthetőbb (természetesen megint nem a konkrét példát nézzétek, mert lehet az hülyeségnek tűnhet, de a bekategorizálás már nem az én feladatom lesz):
Pl.
"Ruházat->Gyerekholmi->Zolni" menüpont a tárolt belső adatbázisból a ruházat->zokni kategóriából a gyereknek való tulajdonsággal rendelkező termékeket fogja leszűrni
"Ruházat->Zolni->Gyerekzokni" menüpont szintlén hasonló szűrőket használ mint fent
Vagy:
"Gyerekholmi->Butor->Fiu gyerekbutór" ugyanoda mutat bent, mint a
"Bútor->Gyerekbutorok->Fiu gyerekbútorok" menüpont
Így egy termék olyan mint ha klasszikus esetet több helyen is szerepelne.
A gyerek bútor a gyerekholmiknál, és a bútoroknál is. Ráadásul, ha még ingyen el is vihető, akkor azon kategóriában is.
Tehát ökörségekre nem lehet majd szűrni, de azért akarnám teljesen dinamikusra megcsinálni, hogy a későbbiekben egy adatbázis sor beszúrásával egyszerűen lehessen módosítani anélkül, hogy ez máshol bekavarna.
Viszont amonrpg amit mondtál az is megfogta most pluszban a fantáziám.
Milyen jó lenne, ha az ügyfél le tudná írni azt mondjuk:
"3 éves kisfiamnak kék ágytakarót keresek."
Tudod ennek a megoldását is?
Nagyon örülnék neki...
[Úgy tudom, hogy elméletileg vannak ilyen rendszerek, vagy rendszer kísérletek amik egy ilyen szövegből ki tudják szedni a hasznos információkat, és abból konkrét paramétereket és értékeket tudnak készíteni.]
Üdv:
Zoli
Na igen
"3 éves kisfiamnak kék ágytakarót keresek."
Tudod ennek a megoldását is?
Nagyon örülnék neki...
Ennek szerintem még a google is örülne :)
Mondjuk ilyen kereséseket már lehet futtatni: ágytakaró kék kor:3év
Ezt már viszonylag egyszerűen tudod parseolni, egyéb esetekben a ragozást és a toldalékokat el kell távolítani, rosszabb esetben szótőt kell keresgélni->külön tudomány...
Szabadszavas
Csak gondolom van benne pár év fejlesztés.
Zoli
Apache Solr
standalone keresőszerver webservice felülettel.
kis gugli :)
Tud nativ nyelvi keresést?
Helyesen felparsolja? Ha igen, akkor megyek és töltöm is lefele.
még mindig tagelés
Ez mennyiben különbözik ezektől a menüpontoktól?
Ruházat: http://domain.hu/?tag=ruha
Gyerekholmi: http://domain.hu/?tag=ruha+gyerek
Zokni: http://domain.hu/?tag=ruha+gyerek+zokni
A piros vagy kék zoknik meg:
http://domain.hu/?tag=ruha+gyerek+zokni+kék|piros
Pont a tag-elt megközelítéssel (rugalmassága) lehet elérni azt, hogy a termék akár az összes kategóriában jelen lehessen. Persze ha nagyon kell, akkor csinálhatsz relációt a tag-ek között, bár én ezt feleslegesnek érzem. (Miért ne keressen a júzer adott esetben egyszerre bútort és zoknit? ha az a heppje, hogy egy keresési eredményben szeretné őket látni?)
Ezen kívül fenntarthatod a szabad tag-re való keresést is, vagy akár a meglévő tag-tábla alapján bármilyen valósidejű szókiegészítéses keresést is tudsz adni. Pl. elkezdi beírni, hogy zo... és dobod neki a zoo-t meg a zokni-t, stb...
Hát, itt max szinonímaszótárral jutsz - nem túl pontos - eredményre, pluszban lehet szótövet vágni, ami megint csak szótárazással valósítható meg, vagy implementálnod kell a magyar nyelv nem éppen könnyű logikáját, minden kivételével együtt (->szótár).
Válasz
1. Ez azt jelentené, hogy minden tag-et nekem kellene definiálni.
2. Ami nem igaz vagy hamis, arra nem jó.
Pl. vegyem fel súlynál:
1.0000 KG
1.0001 KG
1.0002 KG
1.0003 KG
De ha fel is venném, igen nehéz lenne a keresés az ilyen értékekre:
1-10 KG közötti valami.
Vagy rosszul látom?
Üdv:
Zoli
Megoldás!
Jaj, ne.
Ne légy annyira biztos
Végül is, jogos
Szép megoldás lehet, hogy egy megfelelő indextábla/indexadatbázis létrehozása ami csudálatosan denormalizált, és kizárólag a keresést szolgálja. Ettől függetlenül a forrásadatokat megérni annyira normalizáltan tartani amennyire lehet/ésszerű.
Mi "piros"?
"szín:piros;előlap hossza:66mm; ..."
Arány
Nem
A) kompozitált dataok: gyors lekérdezés, lassabb keresés
B) normalizált db: lassabb lekérdezés, gyors keresés
Egy webáruháznál a felvitelek aránya elenyésző lesz a lekérdezésekhez képest. (Hacsak nem apróhirdetés vagy hasonló, ahol a mezei user is vihet fel terméket). Úgyhogy ez az aspektus nem fog túl messze vinni.
Akkor nem értem...
Izé
Értem :)
Hasonlóval én is görcsöltem...
- termekek (id, nev, leiras, ...)
- tulajdonsagok (id, nev)
- termekek_tulajdonsagok (id, termek_id, tulajdonsag_id, ertek_id)
Eddig ugyanaz (kis különbség a kapcsolótáblában: ertek helyett ertek_id), de mivel a különböző tulajdonságok különböző típusú értékekkel rendelkezhetnek (szín-szöveg, hossz-szám...), csinálunk egy ertekek táblát, amelyik csak az azonosítót tartalmazza, (erre mutat a termekek_tulajdonsagok tábla ertek_id-je), majd adattípusonként létrehozunk annyi további táblát, amennyi kell (ezek az Ertek egyedtípus specializáltjai).
- ertekek (id)
- numerikus_erkekek (id, ertek_id, ertek) (UI.: esetleg hozzácsaphatunk egy mertekegyseg mezőt is)
- szoveges_ertekek (id, ertek_id, ertek)
- intervallum_ertekek (id, ertek_id, min_value, max_value)
Így az absztrakt Ertek egyeden keresztül nem csak különböző adattípusú (szám, szöveg) tulajdonságérték, hanem többértékű érték (min-max típusú) is rendelhető egy tulajdonsághoz.
(UI.: Kérdés: hogyan juttathatjuk érvényre azt a megszorítást, miszerint ugyanaz az ertek_id csak egyszer szerepelhet a különböző értéktípusokat reprezentáló táblák egyikében? Egy táblán belül oké, kiteszünk egy "unique"-ot, de hogyan lehet valami egyszerre több táblára nézve unique?)
Ezen kívül, ha csinálunk egy tulajdonsagok_ertekek érvényesítőtáblát akkor korlátozhatjuk egy tulajdonság lehetséges értékeit:
- tulajdonsagok_ertekek (id, tulajdonsag_id, ertek_id)
(UI.: ez esetben nem az ertek_id szerepel a termekek_tulajdonsagok táblában, hanem a tulajdonsagok_ertekek_id)
A dolog szépséghibái:
- Mindig új táblát kell létrehoznunk, ha új adattípus jelenik meg (erre az időben előre haladva egyre kevesebbszer van szükség, sőt az is előfordulhat, hogy már a tervezéskor ismerjük az összes lehetséges értéktípust).
- Sosem próbáltam ki a gyakorlatban.
Új hét
Hétvégén nem volt időm a problémával foglakozni, de ismét teljes erővel belevetettem magam.
foxmulder!
Tetszik a te elképzelésed is, de ennyire nem akartam már szétszedni, mert egy egyszerű dolog kikeresése is már vagy 10 tábla összekapcsolás alapján lehetne kikeresni ami nagy adatbázisok esetén már gond lehet.
De a te modelled egy része szerepel nálam is, csak nem itt, hanem van egy tulajdonság-leíró táblában, mely azt írja le hogy milyen értékeket lehet felvenni/megjeleníteni és a konkrét értékek tárolásánál már nincsenek az intervallumok és társai tárolva.
Röviden a szerkezet a teljesség igénye nélkül az ami mellett maradtam:
Termékek (Ez tartalmazza a termékeket)
-id (egyéni azonosító)
-cat0 (kategória)
-cat1 (alkategória)
-cat2 (al-alkategória)
-Name (termék neve)
-Ar (termék ára)
-.... (további olyan tulajdonságok amik minden terméknél léteznek)
Tulajdonsag (Ez tartalmazza a lehetséges tulajdonságokat amik nem a fő táblában vannak)
-id (egyéni azonosító)
-Tul_Nev (Tulajdonság neve)
-Tul_type (Tulajdonság tárolási típusa)
Tulajdonsag_value (Ez egy kapcsolótábla, melytartalmazza a lehetséges tulajdonságokat amik nem a fő táblában vannak)
-id (egyéni azonosító)
-termek_id (ermék azonosítója)
-tulajdonsag_id (tulajdonság azonosítója)
-value_number (termék tulajdonság értéke, ha az szám [Tulajdonsag->Tul_type határozza meg])
-value_text (termék tulajdonság értéke, ha az szöveg [Tulajdonsag->Tul_type határozza meg])
-value_datetime (termék tulajdonság értéke, ha az idő [Tulajdonsag->Tul_type határozza meg])
Ez volt a tárolás.
Ezen kívül vannak az említett működést leíró táblák:
categoriak
-Cat_ID (egyéni azonosító, ha van rá szükség egyáltalán. Még nem biztos, hogy kell)
-Cat0_ID
-Cat1_ID
-Cat2_ID
-Name (kategória neve)
Ez tartalmazza az összes alá fölé rendelt kategóriát
pl.:
1, 0, 0, 'műszaki cikkek'
1, 1, 0, 'szórakoztató elektronika'
1, 1, 1, 'vedeómagnók'
1, 1, 2, 'televíziók'
1, 1, 3, 'mp3 lejátszók'
2, 0, 0, 'gépjárművek'
Továbbá van egy összekapcsoló tábla, mely tartalmazza, hogy mely kategóriában milyen tulajdonságok léteznek [megjelenítés/termék felvétel]. Ezen kívül itt kerül rögzítésre az is, hogy az egyes tulajdonságok az egyes kategóriákban milyen értéktartományokban vannak értelmezve. (egy telefon súlya más tartományban van értelmezve mint egy teherkocsié)
categoriak_tulajdonsag
-Cat0_ID
-Cat1_ID
-Cat2_ID
-Tul_ID (tulajdonság azonosító)
-Tul_Cat_Name (Milyen néven szereplejen az adott tulajdonság az adott kategóriában. Pl.: autó gyártója, tv gyártója, stb.)
-View_Type (hogyan legyen megjelenítve az oldalon az oldalon az adott tulajdonság. Pl.: telefonoknál a gyártó select listából, DVD lejátszóknál beírós, viszont mivel a gyártó mint tulajdonság tárolási típusa text, ezért mindkét esetben egységesen szöveg ként lenne tárolva az érték)
-MinValue (szám ábrázolás esetén megadja, hogy az adott kategóriában egy bizonyos érték minimum mekkora értéket kell, hogy felvegyen.)
-MaxValue (szám ábrázolás esetén a maximális érték)
-MinLength (szöveg esetén a minimális szöveghossz)
-MaxLength (szöveg esetén a maximális szöveghossz)
Itt kérdés, hogy itt az összeköttetés a kategória, alkategória, illetve al-alkategória mezővel legyen, vagy a kategóriákat leíró egyéni Cat_ID alapján legyen valahogy így:
categoriak_tulajdonsag
-Cat_ID
-Tul_ID
-Tul_Cat_Name
-MinValue
-MaxValue
-MinLength
-MaxLength
Mi a véleményetek erről?
Ti melyiket választanátok?
Tudom, hogy a normalizálás mit mondana, viszont akkor minden egyszerű csoportosítás esetén táblákat kellene összekapcsolni.
Ha simán csak a Cat_ID-s verziót választom, akkor egy műszaki cikkek kategóriába állva, először azt kell eldöntenem, hogy mely kategóriaazonosítók tartoznak az adott szinten egybe. Ezért is a Cat0_ID, Cat1_ID, Cat2_ID hármas a szimpatikusabb számomra az adott esetben.
Természetesen van még 2 tábla ahol hasonló gondom van de félig meddig visszavezethető ide, de ezt most nem akartam bekavarni ide:
-tulajdonsag_set_list (ez tartalmazza select listánál megjelenítés esetén a lehetséges értékeket)
-categoriak_tulajdonsag_set (ez pedig az összekapcsoló táblája)
Előre is köszönöm a segítséget, és az építő jellegű hozzászólásokat.
Ui. (2008.05.14 09:43):
Közben kaptam egy ötletet. Használjak VIEW táblát a kapcsolótáblára. Szépen egyéni azonosítóval kössem össze az adatokat, de a VIEW táblán keresztül könnyen bármit ki tudok olvasni.
A kérdésem, hogy a VIEW csak azt könnyíti meg, hogy szebb selecteket tudjak írni és attól a háttérben mindig végrehajtja a parancsokat, vagy van valamilyen szinten gyorsító funkciója is.
Kategorizálás
Vagyis szerintem a termekek-ben elég csak egy kategoria_id, a kategoriak (vagy categories) pedig nézzen ki így: (id, szülő_kategória_id, név), vagy lásd: hierarchikus adatkezelés SQL-lel PHP-ben I. és II.
A másik az, hogy egy szöveges értékkel kapcsolatban szerintem nem igazán a szöveg minimális vagy maximális hossza (a karakterek száma) a lényeges korlátozó tényező, hanem mondjuk az, hogy egy "szín" tulajdonság értéke 'piros', 'kék' és 'zöld' lehet (és nem mondjuk: 'paprikajancsi').
UI.: Ja, vagy erre vonatkozik a tulajdonsag_set_list? Akkor minek a categoriak_tulajdonsag táblában a MinLength és MaxLength?
Kategorizálás megint
Válasz
Egyben válaszolnék.
"tulajdonsag_set_list" valóban az a tábla ami leírja a lehetséges étékeket mondjuk egy select esetén.
A "categoriak_tulajdonsag" tábla feladata, hogy ha a php oldal megmondja, hogy xyz kategóriában tartózkodik a felhasználó, akkor ott milyen tulajdonságok vannak értelmezve, azok milyen értékeket vehetnek fel.
MinLength és MaxLength akkor kerül érvénybe, ha az adott kategórián belül szöveges adatbekérés van.
pl.: telefonoknál a gyártó neve max 10 karakter lehet, autók esetén max mondjuk 30 karakter.
Mivel nagyon sok féle tulajdonság van, ezért akartam ezeket a dolgokat is SQL-ban tárolni és nem beégetni a PHP kódba.
A kategóriákat azért így gondoltam, mert a 3 szint minden esetben elég az én esetembe arra, hogy meg tudjam határozni, hogy milyen egyéni sajátosságokkal (tulajdonságokkal) bír egy adott termék.
Az a kettőt amit írtál igen érdekesek, sőt a második.... ;)
A kérdésem az, hogy ha a kategória szint nálam kötött, akkor érdemes -e ennyire elbonyolítani, vagy sem.
Minek mi az előnye, és hátulütője.
A Cat0_ID, Cat1_ID, Cat2_ID, -nak az, hogy pofon egyszerűen, nem csak a lehetséges alkategóriákat tudom lekérdezni a "categoriak" táblából (pl.: az mondjuk a műszaki cikkeket alkategóriái....)
, hanem
az összekapcsoló táblából ("categoriak_tulajdonsag") is könnyen le tudom kérdezni egy selecttel a lehetséges tulajdonságokat: (pl.: az mondjuk a műszaki lehetséges tulajdonságai....)
Sőt a ” categoriak_tulajdonsag_set”-ből ugyanígy tudnám a lehetséges választható értékeket is listázni.
Természetesen ennek is van hátránya…
Ha nem teljes általánosságban vesszük a kategóriákat, akkor sem tetszik?
Válasz és kérdés
A szöveges értékeknél viszont tényleg nem értem, miért lényeges a karakterek száma (a példádnál maradva az autógyártók nevei jellemzően hosszabbak, mint a telefonokat gyártók nevei? Tudom, hogy ez csak példa volt, de ilyen szempontból pont jó példa)?
Kategória vs. tulajdonság
"Ruházat->Gyerekholmi->Zolni" menüpont a tárolt belső adatbázisból a ruházat->zokni kategóriából a gyereknek való tulajdonsággal rendelkező termékeket fogja leszűrni
"Ruházat->Zolni->Gyerekzokni" menüpont szintlén hasonló szűrőket használ mint fent
Ebben úgy érzem, keveredik a kategória és a tulajdonság fogalma. A "Ruházat->Gyerekholmi->Zolni" menüpontban a Gyerekholmi tulajdonság, a többi kategória? Vagy épp az a célod, hogy a tulajdonságok és a kategóriák különbsége a user számára el legyen rejtve?
Hasonló fogalomzavart sejtek a tag-elést taglaló diskurzusban, ill. amonrpg 36-os hozzászólásában:
Szerintem a "piros" a "szín" tulajdonság egy lehetséges értéke. Viszont vbence ezt írja a 25-ös hozzászólásban:
UI.: ha a tag-elés elvetve, az egész post sztornó ;)
Tagelés
Válasz ;)
Tehát bent van egy struktúrám, illetve kint van egy menüstruktúrám.
Az, hogy küldő és a belső között mi az átjárás az megvan.
Most a belső struktúráról írtam, amikor is van 3 menüszint (ez elég arra, hogy szét tudjam választani, hogy az egyes tulajdonságokat, mert ami ezen 3 szinten belül van azoknak egyforma tulajdonságokkal is rendelkeznek.)
Kifelé természetesen nem így fog látszódni, mivel ott több féle kategória is lehetséges.
Minden egyes kinti kategória le fog írni egy belső kategóriát/kategóriákat, illetve különböző tulajdonságszűrőket.
Tehát a fenti példánál maradva (kicsit idióta lesz a példa, de talán érthető):
"Ruházat->Gyerekholmi->Zolni" a ruházat főkategória, zokni alkategóriát jelenti ahol az ajánlott életkor tulajdonság 0-16 éves kor között van.
Tehát most az elrejtett belső (fix kategóriaszintű) struktúraábrázolásra keresek jó megoldást.
Üdv:
Zoli
Hurrá :)
Nem ezt oldottad meg a három kategória szinttel (mármint a belső struktúrát)? Inkább a külsővel van a gond (már persze, ha ragaszkodsz ahhoz, hogy a user számára ne legyen megkülönböztethető a halmaz->alhalmaz->al-alhalmaz láncban a kategória és a tulajdonság).
???
Ezt kifejtenéd kicsit, hogy értsem...? ;)
"Nem ezt oldottad meg a három kategória szinttel?"
De igen. Viszont kaptam olyan megjegyzést (nem itt, hanem bent nálunk), hogy nem igazán követi a normalizálás elvét. Miért nem kap a kategóriahármas a ”categoriak” táblában egy egyéni ”CAT_ID”-t amit használhatok a "categoriak_tulajdonsag" összekapcsoló táblában a ”Cat0_ID”, ”Cat1_ID” és ”Cat2_ID” helyett.
Viszont ezzel az volt a problémám, hogy ekkor az összetartozó kategóriákat előbb ki kellene gyűjtenem ahhoz, hogy meg tudjam mondani, hogy pl. milyen tulajdonsággal rendelkezhetnek azok a termékek amik "műszaki cikk"-en belül találhatók attól függetlenül, hogy az ”mosógép”, vagy ”videómagnó”.
Ez a két megoldás között őrlődöm. Hogy inkább könnyű lekérdezésre érdemes ilyenkor fókuszálni (”Cat0_ID”, ”Cat1_ID” , ”Cat2_ID”), vagy inkább arra, hogy normalizált legyen (”CAT_ID”).
Erre volt még a kérdés, hogy ha VIEW táblával áthidalom a problémát, akkor ezzel elérek valamit, vagy csak annyit, hogy számomra egyszerűbb lesz a select megírása.
Tehát nincs gyorsító, egyéb hatása?
Vagy ez így is lassabb lesz mintha közvetlenül a "categoriak_tulajdonsag" táblában egy egyszerű selectel tudnák szűrni?
Üdv:
Zoli
Szerintem...
termékek (id, ez, meg, az....)
kategóriák (id, szülő_kategória_id, név)
termékek_kategóriák (id, termék_id, kategória_id)
(a "kategóriák" helyett megfelel a "tagek" kifejezés is :), lásd: 23-as post)
Ráadásul így egy termék több kategóriában is szerepelhet.
Kifejtés
Nem biztos, hogy szükséges, attól függ, hogy mennyire mosódik össze (ill. válik szét) a kategória és a tulajdonság. Fogalmi szinten. Ahogy a 69-es hozzászólásban elmerengtem: a user számára jól különválasztható, hogy kategória, vagy tulajdonság alapján választ?
Merthogy úgy tűnik a két dolognak vannak közös jellemzői. Mindkettő egyfajta találatszűkítő funkciót tölt be. Azt is mondhatnánk, hogy a kategória is csak egy tulajdonság, ami rendelkezhet Ruhák, Autók, Zoknik stb értékkel (és mellesleg meg van spékelve egy hierarchikus dimenzióval, de ez most lényegtelen).
Csak, hogy értsem
Konkrét példa:
Userünk rátalál a Termékek menüpontra és ráklattyint. Megjelennek az elsődleges termékkategóriák: Autók, Ruházati termékek, Hasadóanyagok... Ezen a szinten még nem jelennek meg tulajdonságok, mert nincs minden terméktípusra egyaránt jellemző tulajdonság (bár elképzelhető, hogy van 30E forintom és el akarom költeni, tök mindegy mire, tehát klattyintok a max 30E Ft tulajdonságra, vagy mindegy mit veszek, csak bio legyen, vagy csak a hazai termékek érdekelnek. Az azért nehezen hihető, hogy mindegy mi a termék, csak piros legyen). Tehát továbbmegyünk valamelyik termékkategóriát követve, például Ruházat. Megjelennek a kategórián belüli alkategóriák (Zoknik, Bugyik...) de egy másik listában azok a tulajdonságok is amelyek a Ruházati termékek kategória szintjén értelmezhetőek (pl.: minta (select: egyszínű, kockás, csíkos...), szezon (szintén select: tavasz-nyár-ősz-tél), méret (gyermek, kamasz, felnőtt, ill. 32, 34, 36, bár ez cipőnél és szoknyánál mást jelent, sebaj, a méret tulajdonságot (ha ilyen egzakt, számszerű) nem a Ruházati termékek, hanem a Zoknik-Bugyik-Szoknyák szinten fogjuk értelmezni)).
Szóval a Ruházati termékeken belül már két listát követhetünk, a további alkategóriákét vagy az ezen a szinten értelmezett tulajdonságokét. Ha az utóbbit követjük (pl.: szezon: téli holmik), akkor az egyik listában ugyanazokat az alkategóriákat látjuk majd, mint az előbb (Zoknik, Bugyik), a tulajdonságlistából pedig kiesett a szezon (hiszen azon belül vagyunk). Kérdés: a szűkítés milyen szintjén jelennek meg a konkrét termékek. Mert, ha már itt megjelennek, akkor ugyebár a kiválasztott tulajdonság alapján szűkítve.
Ha az alkategóriák közül választva megyünk tovább (pl.:Zoknik), akkor az új alkategória lista mellett egy új tulajdonságlista is megjelenik (méret, minta (a minta tulajdonság zoknik esetén nem ugyanazokat az értékeket tartalmazhatja mint az eggyel feljebbi szinten, mert itt már lehet például "garfieldos" is)).
Kérdés: mivel world-s három kategóriaszintet határozott meg, lenne még egy kategóriaszintünk a Zoknik-on belül. A Garfieldos zoknik al-alkategória, vagy a motívum tulajdonság egyik értéke legyen? Persze az lesz, amivé tesszük (elképzelhető egy Ruházat->Alsóruházat->Zokni hierarchia is, ekkor egyértelmű, hogy a Garfieldos egy tulajdonságérték), de én itt valami logikai bibit gyanítok. Ha valami nem egyértelmű, akkor nem hibás valahol az adatmodell?
:)
Köszönöm.
Ez én fejemben úgy született meg a 3 belső kategóriaszint, mert a lehetséges termékeket elnézve úgy néztem, hogy ez a szint elegendő ahhoz, hogy csoportosítani tudjam a tulajdonságokat.
Tehát a "Ruházat->Alsóruházat->Zokni" kategóriában a "Garfieldos" zokni is ugyanolyan tulajdonságokkal (méret, stb.) rendelkezik mint a nem "Garfieldos".
Tehát ez a 3 szintet a belső struktúrában azért gondoltam, hogy pl. egy zokninál né kérjem be termékfelvételkor, hogy dízeles, vagy benzines.
Üdv:
Zoli
Mindez világos :)
Bocs, de még értetlenkedem picit.
Ha nincs rá szükség, akkor mire hivatkoznak a további idegen kulcsok (vagy nem azok?):
-Cat1_ID
-Cat2_ID
A Termékek táblában csak annyit írsz:
-cat1 (alkategória)
-cat2 (al-alkategória)
-Cat1_ID
-Cat2_ID
Valamint a kategória nevét is a categoriak táblában tárolod. Ugyanakkor a Termékek, illetve a categoriak_tulajdonsag táblákban egyaránt számhármasokkal hivatkozol a kategóriára (mondván, hogy mivel kéznél van, így gyorsabb), de a kategória nevéért le kell kérdezned a categoriak táblát.
Válasz
Akkor azt írom ami jelenleg van.
categoriak
-Cat_ID (egyéni azonosító. Ez a kulcsa az összekapcsolásoknak)
-Cat0_ID (meghatározza, hogy az adott kategória mely főkategóriában van. Igazából az alá fölé rendelési viszonyt írja le)
-Cat1_ID (meghatározza, hogy az adott kategória mely alkategóriában van.)
-Cat2_ID (meghatározza, hogy az adott kategória mely alkategóriában van.)
-Name (Ez a alkategória megjelenő neve)
Termékek
Termékek (Ez tartalmazza a termékeket)
-id (egyéni azonosító)
-Cat_ID (kategória azonosító)
-Name (termék neve)
-Ar (termék ára)
-.... (további olyan tulajdonságok amik minden terméknél léteznek)
categoriak_tulajdonsag
-Cat_ID (kategória azonosító)
-Tul_ID (tulajdonság azonosító)
-Tul_Cat_Name
-MinValue
-MaxValue
-MinLength
-MaxLength
Hogy egyszerűen le tudjam kérdezni, hogy egy adott kategórián belül (CAT_ID) milyen tulajdonságok vannak, azt könnyen le tudom kérdezni.
Viszont sokszor a kategória fában nem a legbelső szinten fogok elhelyezkedni.
Ilyenkor nem egy konkrét kategóriára vagyok kíváncsi, hanem az összes a kategórián belül eső alkategóriára is.
(Azért van, mert nem akarom a kintebbi kategóriaszinteken felvenni a lehetséges tulajdonságokat!)
Zoli
Miért így?
-Cat_ID (egyéni azonosító. Ez a kulcsa az összekapcsolásoknak)
-Cat0_ID (meghatározza, hogy az adott kategória mely főkategóriában van. Igazából az alá fölé rendelési viszonyt írja le)
-Cat1_ID (meghatározza, hogy az adott kategória mely alkategóriában van.)
-Cat2_ID (meghatározza, hogy az adott kategória mely alkategóriában van.)
-Name (Ez a alkategória megjelenő neve)
Miért van 3 kategória id? Nem elég egy sima parent_id ami a közvetlen szülő kategória id-je? Így tetszőleges mélységben ágyazhatsz egymásba kategóriákat... Ha meg több kategóriában akarod szerepeltetni akkor kell még egy kapcsolótábla.
Válasz
- először meg kell keresnem, hogy milyen alkategóriák vannak. Ezt a parent_id-vel könnyen meg is tudnám oldani
- viszont ezek után az előzőleg kapott találatokat is tovább kellene boncolnom. Megnézni, hogy melyek azok a kategóriák, melyek parent_id-je az előbb kapottak valamelyike.
És csak ekkor kapom meg, hogy mely kategóriákról is van szó.
Ezek után tudom meg azt, hogy milyen tulajdonságok lehetnek, úgy, hogy a select-be agy IN után felsorolom őket.
Számomra ez a 3-mad, csak azért kell, hogy a különböző tulajdonságsémákat össze tudjam állítani.
Ebbe a hármasba belefér úgy vélem minden.
pl. gépkocsiknál már 2 szint is elegendő:
-gépjárművek->hasznongépjárművek
Ezen belül az összes termék már ugyanolyan tulajdonságokkal rendelkezik (üzemanyag, zöldkártya, stb.)
Inkább lehetne tulajdonság_goup-oknak hívni, hisz az ügyfél felé kommunikált kategorizálás ettől teljesen eltérő lesz. Ezek már csak hivatkozások a különböző tulajdonság-együttállásokra (és ilyenkor szinte ez is kicsit az).
Pl.:
categoriak
Cat_ID, Cat0_ID, Cat1_ID, Cat2_ID, Name
1, 1, 0, 0, Autók
2, 1, 1, 0, Haszongépjárművek
3, 1, 2, 0, Személygépkocsik
.....
Akkor:
autó->diesel->személygépkocsi =====>>>> főkategóra=autók (CAT0_ID=1); alkategória=személygépkocsi(CAT1_ID=2); üzemenyag_tipus=deiesel
Zoli
feladom :)
Na ezt hogyan?
Kezdtem az autókkal, és máris nyílt egy kérdés. Ugye mivel sokféle variáció lehetséges, azért mindent adatbázissal szeretnék leírni.
pl.:
riasztó (lehetséges értékek: nincs megadna, nincs, van)
centrálzár (lehetséges értékek: nincs megadna, nincs, van)
klíma (lehetséges értékek: nincs megadna, nincs, mauális, automata)
vezetooldali_legzsak (lehetséges értékek: nincs megadna, nincs, van)
utasoldali_legzsak (lehetséges értékek: nincs megadna, nincs, van)
oldal_legzsak (lehetséges értékek: nincs megadna, nincs, van)
hatso_oldal_legzsak (lehetséges értékek: nincs megadna, nincs, van)
fugguny_legzsak (lehetséges értékek: nincs megadna, nincs, van)
Ha valaki riasztós autót keres, akkor egyszerű a szűrés.
A valaki centralzáras riasztósat keres, akkor sincs probléma, mert a két tulajdonságot ÉS-elem a lekérdezésben.
Viszont mi van akkor ha valaki azt mondja, hogy mindegy milyen klíma, csak legyen.
Vagy mindegy milyen légzsák, csak legyen, és majd ő eldönti a találatok nézésekor, hogy szimpatikus -e az adott autó.
A légzsáknál ugye azt kellene tudni, hogy az egyes típusokat nem ÉS-el, hanem VAGY-al kellene összekötni, a légkondinál pedig mindegy milyen, csak legyen.
Van egy ötletem, de még nem kavarnák be vele...
Üdv:
Zoli
!nincs
WHERE `klima`!='nincs'
Válasz
Ott több tulajdonság összességét kellene venni.
De a klímánál is meg kellene mondani a van klíma, az azt jelenti, hogy klíma tulajdonság nem "nincs".
Ha mondjuk a színeket nézem, akkor meg, ha olyat szeretnék, hogy világos, sötét, akkor meg ugye azt kell látnom, hogy mely színekre mondtam azt, hogy világos, melyekre hogy sötét.
Ha menürendszerből jövök akkor nincs gondom, hisz akkor az egyes menüpontokhoz tudom rögzíteni a szűrőket.
Viszont ha egy kereső ablakot képzelek el, akkor ugye ott eleve látnom kell, hogy van ilyen megközelítés is.
Pl: összetett keresésnél a légzsákok típusaira kereshetek, egyszerű keresésnél pedig arra, hogy van -e légzsák vagy nincs.
Mivel vagy 400 tulajdonságom lehetséges, és ebből adódóan nem a programba szeretnél beégetni ezeket a tulajdonságokat.
Ezért én arra gondoltam, hogy ezek a tulajdonságok (van légzsák, van légkódi, stb.) felvenném mint tulajdonság.
A tulajdonságoknál lenne egy arra szolgáló mező ami le tudná írni az összefüggéseket. Tehát valahol látszódna, hogy számolt adat.
Viszont, az hogy ezt hol használom fel arra két megoldásom van:
1. mikor felveszek egy új terméket, akkor ezek alapján kiszámolom az összefüggéseket, és utána mint valós tulajdonságot rögzítem. Tehát nem az ügyfél adja meg, hanem az ügyfél egyéb válaszaiból a gép számolja ki.
Előnye, hogy bármikor könnyen elérhető kereséskor, hátránya viszont az, hogy ha felveszek később egy új tulajdonságot, vagy módosítok egy ilyen összefüggést, akkor az összes termékre újra kell számolnom.
2. nem a felvételnél, hanem a kereséskor generálom le ezeket az összefüggéseket. Ez azt jelentené, hogy nekem egy tulajdonság egyik mezőjében lévő értéket a select-ben kellene értelmeznem. Ezt nem tudom hogy lehet.
Ha lehet itt is kerülném azt, hogy először értelmezem az összefüggéseket, majd ez alapján megírom az SQL-t.
Mintha láttam volna valamikor ilyet, de nem tudom hol és nem tudom hogy volt. Mintha generált volna egy változót SQL-ben, amivel összerakta a lekérdezést, majd ezt meg is tudta futtatni. De lehet nem ez a jó út.
Ötletek?...
Vissza az adatmodellezéshez
Azt írják az okos könyvek, hogy már az adatmodell szintjén meg kell oldani az ilyesfajta problémákat és nem az adatokat kezelő program(ok)ra bízni. Az persze kiküszöbölhetetlen (szinte), hogy ne menet közben derüljön ki az ilyesmi.
Szerintem azért tudnál olyan SQL lekérdezést írni, ami mind a négy, légzsákokkal kapcsolatos tulajdonságot lekérdezi és abból ad egy igen-nem választ.
A színekkel kapcsolatos világos-sötét kiegészítés viszont tipikusan utólag megjelent ötlet, úgyhogy vagy szoftveres tákolás, vagy vissza az adatmodellhez. Egy köztes megoldás: A "szín" tulajdonság lehetséges értékei: sötétkék, világoskék, kék... A sötét színek lekérdezése valami ilyesmi: WHERE `szin` LIKE 'sötét'.
De inkább lásd: hozzászólás témája...
Kérdés
(Kicsit leegyszerűsítve írom csak.)
SELECT tul.*,
CASE
WHEN tul.feltetel THEN 'true'
ELSE 'false'
END as type_value
FROM tul, tertul
WHERE ...
És a tulajdon táblában, a feltétel mezőben ez szerepelne:
tulertek.value='maunális' OR tulertek.value='automata'
Megoldható, hogy ez így működjön és kigyűjtse az összes légkondís autót?
Gondolom úgy ahogy leírtam, úgy azt vizsgálná, hogy van -e valami az adott mezőben....
Üdv:
Zoli
Hogyan az OR?
Kicsit egyszerűsítettem az eddig tárgyaltakon.
Kénytelen voltam rájönni, hogy mindent nem tudok megcsinálni MYSQL-ben a szerveren belül.
Az egyszerűsítés annyit jelent, előre beolvasom milyen tulajdonságok is léteznek, vagy melyekre van szükségem. Ez két ponton jelent egyszerűsítést, s így nem kell a MYSQL-nek számolni:
- előre meg tudom határozni, hogy mely mezőben van tárolva egy adott tulajdonság értéke (TEXT, DECIMAL, stb.)
- a fentiekből adódik, hogy szépen meg tudom írni a tulajdonságokat mutató mezőket PHP-ból még.
Viszont most, hogy a kiszolgáló részt írom előjött még egy probléma:
Visszakanyarodva Protezis (12. hozzászólás) kódjára, mely arra adott megoldást, hogy miként tudom megnézni, hogy egy adott termék megfelel -e az elvárt kritériumoknak.
Ehhez a "HAVING"-et használtuk fel "GROUP BY"-al. (sajnos a második miatt elveszek a tulajdonságok, viszont ezt egy beágyazással küszöböltük ki később.)
FROM termekek ter
INNER JOIN termekektulajdonsagok tertul ON ter.id = tertul.termek_id
INNER JOIN tulajdonsagok tul ON tertul.tulajdonsag_id = tul.id
WHERE (tul.nev = "WAP képes" AND tertul.ertek = "igen") OR (tul.nev = "kártya független" AND tertul.ertek = "igen")
GROUP BY ter.id
HAVING megfeleles = 2
A probléma akkor került elő, amikor azt az általános részt írtam, ami az SQL parancs szűrő részét lenne hivatott legenerálni.
Addig nincs gondom a mostani módszerrel, amíg a szűrő feltételei ÉS kapcsolatban vannak.
Viszont amint VAGY-lagos feltétel is szerepel, akkor máris nem tudom számszerűsíteni, hogy ez alapján hányszor szerepelne az adott rekord.
Pl. ha végeredményként ilyet szeretnék szűrni, akkor nem tudom hogy írjam le ha HAVING-el:
Mivel lehet a HAVING módszert kiváltani, mert itt azt sem tudnám megmondani, hogy a HAVING után mit írjak, hiszen nem tudom azt sem meghatározni, hogy hány együttállás szükséges.
Üdv:
Zoli
Mi a vélemyén?
Van e szebb hatékonyabb megoldás arra az alap problémára, ha az ember szűrni szeretne egy olyan szerkezetben, ahol a termékeket és tulajdonságokat egy kapcsolótáblán keresztül köti össze.
Előre is köszi.
Zoli
Kész csőd!!!!!
Valami ilyesmit készít:
Ha csak a belső SELECT-et futattom le, akkor is 145-155 másodperc alatt fut le egy kérés.
Ez ugye így használhatatlan.
Mi a francot lehet ezzel kezdeni?
Nem hiszem, hogy nem lehet megoldani ha a termékeket és a tulajdonságokat egy kapcsolótáblában összekötöm, akkor az egyes tulajdonságokra rá lehessen keresni AND és OR kapcsolattal is.
Ez a struktúra csak akkor működne ha a termék irányból indulnák ki és ez alapján annak a tulajdonságait szeretném látni.
Valakinek valami ötlete?
Üdv:
Zoli
nem szabványos a query
Aztán nem is értem teljesen ezt a felépítést, mi szükség van a subselectre, miért nem lehet a havinget azon belülre tenni...
...amely havingre nincs is szükséged: mert így előbb megcsináltatod a DB-vel teljes kereszt táblát, majd csak ezután állsz neki szűrni. Minimum a belső queryben kéne szűrnöd, de a MySQL ilyesmiben nem a legokosabb, ezért a biztos, hogy egy online view-t (subselect) csinálsz, amiben már csak a leszűrt termékek vannak, és ehhez joinolod a másik táblát.
Végül meg nézd, hogy a tertul táblán van-e Product_ID mezőn index. Szerintem nincs, és ez is drsztikusan ronthatja a query teljesítményét, meg szépen föleszi a szervert is.
Üdv,
Felhő
Szia!
Amúgy kiderült, hogy egy elég gyenge gépen a tesztgép.
Most áttettem egy jóval nagyobbra (4 magos és 4GB memória a 128MB helyett).
Ekkor olyan 14 másodperc alatt fut le (jóval jobb, de még mindig brutális), viszont a második futatás már 0.005 alatt is lefut.
Viszont ebből is látszik, hogy még van mint javítani:
-"Group by esetén nem kérdezhetsz le nem aggregált mezőt anélkül, hogy egy aggregátor függvényt használnál rá."
Ezt nem teljesen értem.
-"mi szükség van a subselectre" nem mindig van subselect. Csak akkor ha olyan mező van a lekérdezésben ami nem létezik magában az adattáblában, hanem csak számolt együttállásokból adódik. A belső SELECT-be szerintem is be lehet emelni azokat a szűrőket ami valódi tulajdonságokat tartalmaznak.
Azért nem tettem, mert egyenlőre még nem tudom hogy bontsam szét az eredeti feltételt a PHP-ban ami az SQL-t generálja:
1. a valódi mezők lekérdezhetők a belső SELECT-ben
2. a számolt mezők csak kívül
3. ha a számolt mező valamilyen együttállásban van egy virtuálissal, akkor ezeket a valódi mezőket is csak kívül lehet összefüggéseiben vizsgálni
Szerinted segíthet a dolgon ha szűkítem akkor az összekapcsolandó táblák mennyiségét?
Holnapra ilyesmi dolgokat szeretnék lepróbálni:
1. A belső SELECT-ben nem az összes terméktulajdonságot venném, hanem csak azokat a tulajdonságokat amiket fel is használok.
Még gondolkodom ezt hogyan tudom megtenni.
Van esetleg valami jó ötlet még? Amiket kigondoltam azoknak lehet hatása a futásra?
Tényleg: hogyan lehet a táblákat becachelni? Mivel azt tapasztaltam, hogy ha egymás után többször kérdezek le, akkor a futás idő jóval kisebb.
Előre is köszönöm.
Üdv:
Zoli
query cache
2. a számolt mezők csak kívül
"
HAVING `gyarto`='Audi' AND `uzemenyag`=2 AND `tipus`='A3' AND `van_legzsak`='true' AND `muszakivizsga_ervvege` = '2008-08-21 15:07:04'"Csak valahogy nem értem ezt a lekérdezést (de azt igen, hogy mit nem láttam az előbb :)), mert akkor ezesetben a másik irányból kéne megközelíteni. Először kérdezd le a tulajdonságok közül azokat az id-kat, amiknek meg van mondjuk mind a 4 tulajdonsága egy subselectben, és ehhez joinld a termék táblát. Erre a queryre egy kis trükk:
select id from tags where tag = 'value1' OR tag = 'value2' OR tag = 'value3' group by id having count(*) = 3, tehát az a szám van a feltételben, ahány tulajdonságra vizsgálsz.Most látom, hogy ilyesmi irányba mentél el a második felében a hozzászólásofnak, csak ez a having rész hiányzik.
Az index meglétét nézd meg, az akár százszoros vagy még durvább növekedést jelenthet. Amúgy is nézd meg a queryd explainjét, és abban egyből fog látszani, hogy a joinhoz használ-e indexet.
Üdv,
Felhő
Válasz.
"group_concat is egy ilyen függvény"
Ahogy írtad az lenne a jó, ha ezt a függvényt ki tudnám váltani egy olyanra ami azt az értéket veszi ki amelyik nem NULL. Csak ilyet egyenlőre nem találtam. Így akkor ezek a mezők eleven BLOB-ként jönnének ki, hanem az INT IND, a DATETIME, DATETIME, stb.... Talán az index itt is jobban érvényesülne. Vagy ezt az aggregáló függvény nekem kell valahogy megírni?
"Csak valahogy nem értem ezt a lekérdezést"
A `van_legzsak` tulajdonság nem létezik. Ezt más tulajdonságok együttállásából számolja. Viszont ezek csak a GROUP BY után áll rendelkezésemre, mikor egy sorrá tudom nyomom össze a tulajdonságokat.
Sajnos a valódi ALIAS-okat (pl. gyarto, tipus, kivitel, stb.) nem tudom egy SELECT-en belül felhasználni.
"tehát az a szám van a feltételben, ahány tulajdonságra vizsgálsz"
Tehát ez hasonlít ahhoz ami egy kezdeti verzióban volt (18. hozzászólás), csak is az értéktartomány szűrésére.
Ha ezt esetleg kombinálnám a holnapi 2. kísérletemmel, akkor azok is kiesnek amik durván kiesnek egy bizonyos értéktartományomon.
"Az index meglétét nézd meg" Vannak index-ek, viszont meg fogom nézni, hogy megfelelőek -e.
Üdv:
Zoli
Teszt
Az vettem észre, hogy minél jobban le szeretném szűrni a tartományt annál lassabb a kérés:
(RESET QUERY CACHE használva)
A tábla így néz ki:
EXPLAIN
Az érdekes, hogy
Zoli
Előre legyártás?
Lehet -e megoldás az, hogy mondjuk egy script 10 percenként elkészít egy táblát amibe az összes termék összes tulajdonságát összerakom.
Ezt arra használnám, hogy a keressek benne.
Igaz, hogy bazi sok mezeje lesz, de kevés rekordot fog tartalmazni.
Ráadásul szépen lehet keresni benne.
Persze az alap adatokon kívül nem tudom a többit hogyan lehetne indexelni.
Mi a véleményetek róla?
Nem tudom hasonló okok miatt van -e pl. a Va*erán is 1/2 órás késés az új aukciók kiírásakor, vagy ott ezt ellenőrzésre használják
Üdv:
Zoli
Teszt
Igaz PHP-t kellett írnom hozzá, hogy legenerálja nekem az SQL parancsokat amit utána a PHPMYADMIN-ba beilleszthetek.
Az elkészült tábla: 164 mező+ a termék táblában tárolt pár alap mező és 50.000 terméket tartalmazz.
Méretileg ez fele annyit eszik mint maga az alap kapcsolótáblám.
Az eddig példaként használt SELECT pedig 14-17 másodperc helyett 0.2758 másodperc alatt futott le, úgy hogy csak a termék ID alapján van indexelve, amit a lekérdezésben nem használok fel.
Elég csúnya a megoldás, de úgy néz van benne fantázia. Bár kérdés, hogy ha már 500-700 mezős a tábla, akkor mit szól hozzá?
Van egyáltalán határ?
Üdv:
Zoli
termékkereső
Hol tart a termékkereső fejlesztése, esetleg működik már ki lehet próbálni?
Üdv,
ch