Termékek különböző tulajdonságok json vs table
2017-05-13T04:03:43+02:00
2017-05-22T17:16:41+02:00
2022-08-10T16:15:30+02:00
konkon
Sziasztok!

Az a gondom, hogy adott  sok termék vannak alap tulajdonságai mindnek (pl név, ár, stb), illetve vannak olyanok amik nem mindhez tartoznak, van a melyiknek kell hosszúság, szélesség, van amelyiknél nem, van ahol kell szín, magasság. Ezek közt van olyan amikkel kell majd számolni is kell. Where-ben is szerepelhetne ilyen tulajdonság. Join-ban nem (illetve nehezen tudok elképzelni ilyen esetet).

A json típusú mezővel ugyan találkoztam már, de aktívan még nem használtam, szerintetek mi lenne a célszerű ezt használni, vagy a különféle tulajdonságcsoportoknak hozzak létre egy-egy táblát és azt csatoljam a termékekhez? Nem lenne végtelen számú tulajdonság halmaz, de azért 10-20 biztosan.
Mutasd a teljes hozzászólást!
Több lehetőséged is van:

1. Az egyik az EAV model, amit "djjjozsi" is írt. Itt előny a rugalmasság, de cserébe sok tulajdonság esetén komplex lekérdezések kellenek és bizony a teljesítmény is borzalmas lesz. Rákereshetsz, hogy miért tartják sokan egyenesen anti-patternnek. (Én nem megyek bele a kérdésbe, hogy az-e.)

2. Csinálhatsz olyat is, hogy a termékek alaptulajdonságait egy közös táblába teszed, míg a kategóriaspecifikus tulajdonságokat mindig egy-egy kapcsolótáblába. Ebben az esetben sokkal egyszerűbbek lesznek a lekérdezéseid, jobb lesz a teljesítmény is, de cserébe mindig módosítani kell adatbázist, amikor új terméktípust, vagy akár csak egyetlen új tulajdonságot veszel fel (vagy éppen módosítasz). Ez nem feltétlenül hátrány, de számolni kell vele.

3. Csinálhatsz egy "végtelenül" széles táblát, amibe minden tulajdonságot beleteszel. Itt két hátrány jelentkezik: egyrészt a tábla szélesedésével a lekérdezések sebessége is romlani fog (nem csupán a sorok száma számít), másrészt itt is igaz, hogy egy új tulajdonság, adatbázis módosítást igényel. Hátrány még, hogy tele lesz felesleges üres - null, 0, üres sztring (a mező típusától függően) - értékekkel a táblád.

4. Ha véges számú egyedi tulajdonságokkal lehet számolni, akkor a 3. opciónak lehet egy variációja, hogy általános mezőket használsz (pl. attribute_1, attribute_2 stb.). Illetve ezeket az általános mezőket érdemes legalább szám és sztring típus szerint szétválogatni. Ebben az esetben az alkalmazásodnak kell tudnia, hogy pl. az attribute_1 az kijelzőfelbontást, színkódot, vagy éppen alkoholtartalmat jelöl az adott termék esetében.

Mindegyik megközelítésnek van előnye illetve hátránya. Nekem - úgy nagy általánosságban - a 4. opció a legszimpatikusabb, de a döntést neked kell meghoznod.

Kiemelném, hogy most az adatok tárolásáról beszélünk. Keresésre, nagy terheltség esetén semmiképpen sem SQL-t használnék, hanem pl. Elasticsearch-öt (most már csak elastic a neve). Az sémamentes, szóval nem lesz gondod a termékek egyedi tulajdonságaival. De mivel ott is kellenek indexek a hatékony működéshez, és feltehetően nem akarsz számos teljesen különböző index-szel bajlódni, a 4-es opció, megint csak ad némi előnyt. De a döntést most is a tied... :)

Szerintem kaptál annyi opciót, amivel már el kell, hogy tudj indulni.
Mutasd a teljes hozzászólást!

  • Bár kissé zavarosan fogalmaztál, de most nem úgy van, hogy ->
    Van termek_table, van termek_adat_table, stb és ezekből kérsz le egy-egy adott terméket, vagy listázol ki valamennyit megadot bemeneti feltétel alapján, majd megjelenítesz a felhasználónak ezen adatokból annyit amennyit éppen célszerű?
    Miért lenne baj, ha egy adott terméknek nincs olyan adata, mint egy másinak, ezért az adott tulajdonság-oszlop üres?
    Miért kellene ezért akár 20 féle "termek_adat_table", ha jól értem?
    Mutasd a teljes hozzászólást!
  • Szerintem a normalizálásra gondol, azaz a tulajdonságértékek redundanciájának elkerülése végett áttenné őket másik táblába és külső kulccsal hivatkozna rájuk, ha jól értem. A többihez nem értek... :)
    Mutasd a teljes hozzászólást!
  • Amit JSON-ba csomagolsz, azt műveletvégzés előtt ki kell csomagolni. Ugyan ez az "előtt" lehet akár rögtön a beillesztésnél is (MySQL :: MySQL 5.7 Reference Manual :: 14.1.18.9 Secondary Indexes and Generated Columns ), ez nem pont az, amit szeretnél.
    Ex-has inkább egy olyan táblában gondolkodnék, ahol termékId, tulajdonság és érték oszlopok vannak, ahol a termékId-tulajdonság páros egyedi (ettől még persze be is lehet számozni őket). Indexelni meg elég sokféleképpen érdemes, attól függően, hogy mire is akarsz keresni.
    Mutasd a teljes hozzászólást!
  • Lehet a tervezéssel kéne inkább kezdeni a dolgot, vagy újrakezdeni szerintem.

    a különféle tulajdonságcsoportoknak hozzak létre egy-egy táblát és azt csatoljam a termékekhez

    Semmiképp se hozzá létre annyi táblát ahány tulajdonságod van!


    termekek tábla
    temrekid (PK)
    termeknev
    ...

    tulajdonsag_csoport
    csoportid (PK)
    csoportnev

    tulajdonsag_ertek
    ertekid (PK)
    csoportid (FK)
    ertek

    Kapcsolótáblában tárolod termékhez milyen tulajdonság-értékek lettek kapcsolva
    termekek_tulajdonsagok
    termekid (FK)
    ertekid (FK)

    Ebből már tudsz szűrést készíteni hatékonyan, azonos értékű termékeket tudod listázni.
    Ami fontos egy összetett szűrésnél, hogyha keresel ("kék" vagy "piros") termékekre, amik (10MP vagy 5MP) felbontásúak, akkor ezt a két tulajdonság típust ÉS -sel kérheted le.

    JSON -nál ilyen dinamikus feltételt nehezebben készíthetsz el, bár megoldható. Használhatod az adott fejlesztői környezet beépített lehetőségeit.
    Mutasd a teljes hozzászólást!
  • Több lehetőséged is van:

    1. Az egyik az EAV model, amit "djjjozsi" is írt. Itt előny a rugalmasság, de cserébe sok tulajdonság esetén komplex lekérdezések kellenek és bizony a teljesítmény is borzalmas lesz. Rákereshetsz, hogy miért tartják sokan egyenesen anti-patternnek. (Én nem megyek bele a kérdésbe, hogy az-e.)

    2. Csinálhatsz olyat is, hogy a termékek alaptulajdonságait egy közös táblába teszed, míg a kategóriaspecifikus tulajdonságokat mindig egy-egy kapcsolótáblába. Ebben az esetben sokkal egyszerűbbek lesznek a lekérdezéseid, jobb lesz a teljesítmény is, de cserébe mindig módosítani kell adatbázist, amikor új terméktípust, vagy akár csak egyetlen új tulajdonságot veszel fel (vagy éppen módosítasz). Ez nem feltétlenül hátrány, de számolni kell vele.

    3. Csinálhatsz egy "végtelenül" széles táblát, amibe minden tulajdonságot beleteszel. Itt két hátrány jelentkezik: egyrészt a tábla szélesedésével a lekérdezések sebessége is romlani fog (nem csupán a sorok száma számít), másrészt itt is igaz, hogy egy új tulajdonság, adatbázis módosítást igényel. Hátrány még, hogy tele lesz felesleges üres - null, 0, üres sztring (a mező típusától függően) - értékekkel a táblád.

    4. Ha véges számú egyedi tulajdonságokkal lehet számolni, akkor a 3. opciónak lehet egy variációja, hogy általános mezőket használsz (pl. attribute_1, attribute_2 stb.). Illetve ezeket az általános mezőket érdemes legalább szám és sztring típus szerint szétválogatni. Ebben az esetben az alkalmazásodnak kell tudnia, hogy pl. az attribute_1 az kijelzőfelbontást, színkódot, vagy éppen alkoholtartalmat jelöl az adott termék esetében.

    Mindegyik megközelítésnek van előnye illetve hátránya. Nekem - úgy nagy általánosságban - a 4. opció a legszimpatikusabb, de a döntést neked kell meghoznod.

    Kiemelném, hogy most az adatok tárolásáról beszélünk. Keresésre, nagy terheltség esetén semmiképpen sem SQL-t használnék, hanem pl. Elasticsearch-öt (most már csak elastic a neve). Az sémamentes, szóval nem lesz gondod a termékek egyedi tulajdonságaival. De mivel ott is kellenek indexek a hatékony működéshez, és feltehetően nem akarsz számos teljesen különböző index-szel bajlódni, a 4-es opció, megint csak ad némi előnyt. De a döntést most is a tied... :)

    Szerintem kaptál annyi opciót, amivel már el kell, hogy tudj indulni.
    Mutasd a teljes hozzászólást!
  • Köszönöm mindenkinek a hozzászólást!

    Egyenlőre a json-ról mindenképp letettem, leginkább Subi77 által felvetett 2 verzió tűnik most jónak, ezért az ő válaszát fogadom el, bár magam sem tudom mi lenne a teljesen igazságos.
    Mutasd a teljes hozzászólást!
abcd