Webáruház - kategorizálás elméletben

Ha egy alágat jó lenne 2 (vagy több) helyen is megjeleníteni, akkor sem árt a parent. Nagyon egyszerűen lehet ilyet trükközni

Azert en ilyet nem tennek. Megvannak ennek is a hibai. Ha surun van modositva a fad, akkor altalaban jobb a parent/child.

Ez durva. A parent-es hlyeséget örökre kilőttem az életemből.

baccus. télleg.
köszi!

left < 8 and right > 9 order by left asc

Igazabol csak elsore tunik bonyolultnak, mert nem a megszokott szulo/gyerek felfogas. Emlekszem, hogy kabe egy hetig kinlodtam vele, mire teljesen megertettem, hogy hogy mukodik. Valahol lattam megvalositast mysql tarolt eljarasokkal. Az mondjuk tenyleg kenyelmesebb, mert a left/right ertekeket elfelejtheted, csak id-vel kell foglalkozni. Kivulrol. :]

itt szerintem ugyanez a módszer van kifejtve magyarul kész kódokkal

Azért közben elgondolkodtam a dolgon. Tényleg nagyon ötletes, de ember legyen a talpán, aki ezt egy nagyobb webshop-ra összerakja. Igaz, csak egyszer kell, de az egy A3-as lapot elvinne és nagyon alaposan oda kellene figyelni, mert könnyű hibázni.
Vagy kellene hozzá írni egy segédprogit.

szerk:
Nem kötözködés, csak még valószínűleg nem látom át:

Hogy jutok el a banántól a food-ig egy lekérdezéssel?

Nem vagyok róla meggyőződve, hogy a fgv gyorsabb mint a LIKE, ennek ellenére az ellenkezőjét sem merném állítani (ki kellene próbálni), ugyanis mindkét esetben minden egyes rekordon el kell végezni a műveletet és a tablescan az ami lassú.

Az igazi az lenne, ha számként kezelnénk és egy between-el keresnénk (természetesen index használatával).

szerk:
ehhez nem is kellene mást csinálni, mint kiegészíteni 0-kal a kategóriakódokat, tehát:

Hamár...

Modified Preorder Tree Traversal

Nem kell like-kal okorkodni, nem rekurziv, nem csak leszarmazottakat, de osszes ost lekerdezheted egy selecttel, gyors, oda-vissza atjarhato az adjacency modellel, es mivel a kategoriafat nem szokas percenkent atrendezni, igy az egyetlen gyengesege (fa atrendezesekor, modositaskor potencialisan n/2 rekord update-je) kiutve.

Árnyék megoldásához hozzá kell adni stl megoldását (tehát redundanciát kell direkt csinálni!), és éppen azt a szerkezetet kell használni, amelyik az eredményesebb. Ha rekurzív lekérdezés kellene, akkor str megoldása a jobb, mert az nem terhelő és nincs rekurzív lekérdezés-dömping, ha oldalról-oldalra, kategóriáról-kategóriára lépkedés kell kulcsok alapján, akkor Árnyék megoldása a jobb.

Stl megoldása helyett, inkább azt módosítva, lehet még a kategóriák fa-szerkezetének cachelésére az is, ha a kategóriák vesszővel elválasztva vannak felsorolva, a helyőrző számok helyett csak simán számokként. Ez esetben a LIKE helyett pl. a FIND_IN_SET() használatos.

Szia

Konkrét példa sok elmélettel. Szerintem pont ez kell neked.

Adatbázis tervezés elmélet + webshop megvalósítás SQL

Használd egészséggel, tényleg egész érdekes.

Én is őrá szavazok. Szerintem nagyon egyszerű-nagyszerű megoldás. Ráadásul kezelni se nehéz tetszőleges mélységig működik. Rekurzívan lehet listázgatni, vagy bejárni, mint egy fát.

Szia

Like-al nem biztos hogy túl jó listázni, mert nagy adatmennyiségnél már elég lassú tud lenni. Vannak erre mysql stringkezelő függvények.

Mindenképpen segédtáblás megoldást ajánlanék én is és el kell gondolkodnod azon is, hogy mik lesznek a kapcsoló mezők szűrésekhez, és különféle csoportosításokhoz, valamint a redundancia.... Szóval szerintem rajzolj sokat, próbáld meg grafikusan is összekapcsolgatni a táblákat. Egyszer ki fogja magát forrni :D

Aklasszikus megoldáson túl lehet használni karakteres kategória-kódokat is:

01: alaplap
0101: AMD procihoz
010101: Socket 940
010102: AM2+
010103: AM3
...
0102: Intel procihoz
010201:

02: processzor
0201: AMD
020101: AM2+
0202: Intel
020201:
0203: Egyéb
...
03: VGA
0301: AMD
030101: AGP 8x
030102: PCI-E
0302: NVidia
...
0303: Intel
...
04: HDD
0401: IDE
0402: SATA
0403: SATA2

Hátránya: több helyet foglal, mint az integer
Előnye: LIKE-al egyben listázhatod az alkategóriákat és azok összes termékét. Nem kell rekurzív lekérdezést írnod.

Az n-m kapcsolatot meg árnyék már leírta.

Tegyük fel, hogy van egy táblád az összes termékről. Ezeket csoportosítani kéne, mert egyben az egész lista túl hosszú.

A legegyszerűbb felvenni a termék adatai mellé egy plusz mezőt, amibe valami csoportosításra alkalmas érték kerül, mint mondjuk a termékcsalád (desktop, laptop, alaplap, diszk, stb). Adatrögzítéshez, csoportok listázásához jól jön egy segédtábla, amibe a csoportnevek kerülnek.

Hmmm, még mindig túl hosszú listák jönnek ki. Akkor vegyünk fel még egy csoportosító mezőt, ami a termékcsaládokat osztja fel alcsoportokba. A diszkeket méret, a desktopokat meg gyártó szerint szeretnénk alcsoportokra bontani. Ki kell egészíteni a segéd táblát is, hogy az első szinten található főcsoportok, második szinten alkalmazható alcsoportjai könnyen listázhatók legyenek.

Szükség esetén az újrafelosztás akárhány szintűre megcsinálható:


Vagy valami ilyesmi. A lényeg, hogy a szintek száma előre rögzített, minden termékre ugyanannyi, a segédtáblába pedig bekerül az összes lehetséges csoportosítás, vagyis a teljes N szintű fa. (Több termék tábla esetén ez nyilván táblánként értendő.)

A rondaságon kívül más bajok is vannak ezzel a fajta csoportosítással, de ennél egyszerűbbet nem tudtam kitalálni.

Sztenderd megoldás:

kategoriak tábla:
kategoria_id, kategoria_nev, szulo_kategoria_id

szulo_kategoria_id NULL vagy 0, ha legfelsőbb szintű kategóriáról van szó, és a szülő kategória id-je, ha alsóbb szintű kategóriáról van szó.

Egy termék több kategóriába történő besorolása pedig klasszikus n:m-es kapcsolat leképezése egy kapcsolótábla segítségével 2db 1:n-es kapcsolatra.

Sziasztok!

Lenne egy nagyon nagy kérdésem hozzátok! Van egy saját webáruház motorom, amely működik már rendesen de lenne vele egy kis gondom. Ahogyan a termékeket kategorizálom benne, az nem az igazi. Nagyon fapados és egy módon működik csak, de ezzel nem akarok untatni senkit sem.

Szóval a lényeg az lenne, hogy olyat szeretnék, hogy létrehozok kategóriákat pl.

Procik, memóriák, alaplapok
Ezeket a kategóriákat felruházom egy olyan tulajdonsággal, hogy "főkategória"!

Majd létrehozok néhány új kategóriát pl.:
LGA775, AM2+, Socket939 stb.

Majd ezt a 3 kategóriát, hozzá tudom csatolni a procikhoz! Majd mondjuk az AMD proci termékeket vagy AM2-nek vagy Socket939-hez csatolom.

Ez lenne az első kérdésem, hogy hogyan tudnám ezt lehető legegyszerűbben megoldani? Tehát kategóriák "alá" becsatolni újabb kategóriákat! (De persze olyan eshetőség is lenne, hogy egyből egy "főkategóriából következnének" a termékek.)

A másik kérdésem pedig az lenne, hogy ha lennének oylan termékek, amelyek akár 2 teljesen különböző kategóriába is kellenének akkor azokat hogyan oldjam meg? Teszem azt lenne olyan processzor ami belemegy Intel LGA775-be is, és AMD AM2+-ba is!

Igazából nem konkrét kódokat várok tőletek, hanem, hogy mi a véleméynetek? Mi lenne a legegyszerűbb megoldás, milyen megvalósításra és milyen táblákra lenne szükségem az sql-ben?

Előre is köszönöm!