PHP dinamikus termékjellemzők
2015-07-15T10:17:22+02:00
2015-07-15T14:34:23+02:00
2022-08-09T17:15:30+02:00
juniorprogramozo
Sziasztok!

Egy webshop elkészítésén dolgozom jelenleg és a segítségeteket szeretném kérni. Olyat szeretnék megvalósítani, hogy vannak termékek, a termékek kategóriákba sorolhatóak. A kategóriákhoz egyedi jellemzők rendelhetők. Ezek a jellemzők nem fixek, hanem dinamikusan bővíthetőek. Ezzel nem is lenne probléma, csak az adott kategórián belüli termékekhez mindig menteni kell a jellemzők szerinti értékeket is.

Minden okés lenne, csak a jellemzők ilyenfajta tárolása fejtörést okoz számomra. Igazából iránymutatásra lenne szükségem, hogy melyik a legjobb megoldás ennek a megvalósítására.

Én olyanon gondolkozom, hogy mindent adatbázis táblákban tárolni és onnan visszakérdezgetni majd külön elmenti, viszont ez rengeteg tábla / mező kapcsolattal jár. A másik, hogy json_encode segítségével egyetlen mezőben (asszociatív tömbökkel dolgoznék) tárolni minden jellemzőt, amit folyamatosan frissítgetnék, majd a termékekhez tartozó értékeket külön elmenteném. Tovább nehezíti a dolgomat, hogy a jellemzőkkel dolgoznom is kell a későbbiekben, nem csak letárolni.... könnyen hozzáférhetőnek kell lennie egy kereső miatt... :)

Érdeklődni szeretnék, hogy jó úton járok-e vagy esetleg milyen megoldást javasoltok számomra. Nagyon szépen köszönök mindenféle segítséget! :) :)
Mutasd a teljes hozzászólást!
Szia,

Miért kellene ehhez rengeteg tábla? elég 4 db ( több szintű kategóriákkal még további kapcsolótáblákkal akkor is max 5-6)

1) Termék tábla / termék alap jellemzői, ami minden terméknél szükséges, kategória_id

2) Kategória tábla  / Kategória jellemzői

3) paraméterek tábla / ebben tárolod, hogy milyen extra paraméterek tulajdonságok vannak /

4) parameterek_kategória_kapcsolat tábla / ezzel kapcsolod össze a paramétereket és a kategóriákat / saját_id, paraméter_id , kategória_id /
Mutasd a teljes hozzászólást!

  • Életemben nem fejlesztettem webáruházat. Bár 'junior' koromban voltak ilyen ambícióim. De aztán fogtam egy kiforrottat (említésre méltókból van több tucat is, a teljes paletta meg kismillió) és azt pofozgattam jobbról-balról az igények szerint.

    Nem fogom eldönteni helyetted, hogy milyen úton jársz, de én biztosan több táblát használnék és azokat kapcsolnám össze a lekérdezéskor.
    Mutasd a teljes hozzászólást!
  • Szia,

    Miért kellene ehhez rengeteg tábla? elég 4 db ( több szintű kategóriákkal még további kapcsolótáblákkal akkor is max 5-6)

    1) Termék tábla / termék alap jellemzői, ami minden terméknél szükséges, kategória_id

    2) Kategória tábla  / Kategória jellemzői

    3) paraméterek tábla / ebben tárolod, hogy milyen extra paraméterek tulajdonságok vannak /

    4) parameterek_kategória_kapcsolat tábla / ezzel kapcsolod össze a paramétereket és a kategóriákat / saját_id, paraméter_id , kategória_id /
    Mutasd a teljes hozzászólást!
  • SmithGab féle megoldás kezdetben jó lenne, csak kimaradt egy tábla ahol a paraméter ID és Termék ID -val tárolod az adott értéket.

    Illetve ennek még egy olyan hátránya van, hogy keresni már nehezebb lesz, mint ha 1 táblában lennének az adatok.
    Esetleg úgy tudod kikerülni, hogy ha termékek táblájához adsz új sort, és paraméter táblában ennek az elnevezését elmented...
    Persze ez meg azt eredményezi, hogy ha sok termék, és paraméter van, hogy gigászira nő a táblája.
    Amit még úgy tudsz csökkenteni, hogy kölön veszed az alap termékek táblától, és külön táblába tárolod és bővíted, ekkor könnyebb keresni de rengeteg üres mező is lesz, amire azért figyelni kell.
    Illetve ha ezt a tábla toldásos megoldást vállasztod be állíthatod a paraméternél hogy milyen típusú mező, így lehet int, varchar, vagy épp text, és hogy indexelni kell, mert keresel majd benne, vagy sem.
    Ez azért sokat dob a sebességen, de még így is lomha lesz kellő memória cache nélkül.
    Mutasd a teljes hozzászólást!
  • Igen kimaradt az érték tábla (paraméter <=> termék)
    Valószínűleg most még nem egy profi webshopot szeretne összerakni.
    Mutasd a teljes hozzászólást!
  • Nagyon szépen köszönöm! Én is hasonlóban gondolkozom, még azon forgok kicsit, hogy mivel kategóriánként változhat a jellemzőkhöz tartozó értékek száma (van ahol 2 érték lehetséges vagy ahol több), azt hogy tároljam a paraméterek táblában, lenne benne egy paraméter azonosító mező (esetleg itt eltárolhatnám a kategória azonosítóját is és akkor nem kell összekötő tábla), egy név mező és egy értékek mező, amiben js_encode-dal vannak tárolva a lehetséges értékek (bár ez a keresésnél körülményesebb), másik opció amire gondolok, hogy paraméter tábla: paraméter azonosító mező, név mező és X db érték mező (ami egy maximális érték lenne a jellemző értékeinek számára), csak így sok mező maradhat üresen...

    Nagyon szépen köszönöm a választ! Minden vélemény / segítség hatalmas támogatás számomra! :)
    Mutasd a teljes hozzászólást!
  • Nagyon szépen köszönöm a választ! Ez is nagyon hasznos számomra! :)) De remélem nem gond, hogyha a pontot SmithGab-nak adom! :)
    Mutasd a teljes hozzászólást!
  • Köszönöm a választ, valószínűleg ez az út lesz a legjobb. :)
    Mutasd a teljes hozzászólást!
  • Tipikus probléma webshopoknál, ezért neve is van :) EAV pattern-re keress rá, rengeteg megoldás létezik. Ha esetleg Doctrine - Symfony vonalon mozogsz, nézd meg a bundleöm is: Padam87/AttributeBundle
    Mutasd a teljes hozzászólást!
  • Codeignitert használok a munkáimhoz :) Időközben kialakult egy kép bennem, hogy hogyan is tudnám megoldani pár plusz tábla segítségével, ami könnyíti a munkám,  de nagyon szépen köszönöm a tippet, utánanézek. ;) :)
    Mutasd a teljes hozzászólást!
abcd