ugrás a tartalomhoz

Legoptimálisabb termék tulajdonság kezelés

danmail · 2013. Júl. 19. (P), 07.39
Sziasztok,

Szeretnék segítséget kérni abban, hogy az én élképzelésemben mi lenne a legjobb módja a termékek tulajdonság kezelésére.

Ez lenne az eredeti koncepció:


Vagyis vannak a termékek.
Vannak a tulajdonságok.
Van egy tulajdonság érték tábla amiben a tulajdonsághoz kapcsolt értékek vannak.
És van egy kapcsolótábla ami megmondja hogy melyik terméknek milyen tulajdonság értékei vannak.

A legnagyobb akadályba a keresésnél ütköztem.
Olyan keresést szeretnék indítani ahol azokat a termékeket kapom meg amiknek mondjuk 2 megadott tulajdonsága be van állítva és a tulajdonság értéke 2-3 érték közül valamelyik.

például:
azt a terméket ami ('kék' VAGY 'piros' VAGY 'sárga') ÉS ( '10kg' VAGY '20kg')

Nyilván a kék, piros, sárga és a 10kg, 20kg 1-1 tulajdonság értékei.

Eddigi kisérletezések alapján úgy látom, hogy ebben a struktúrában elég nehézkes lenne ilyen keresést végrehajtani. Vannak működő query-k, de túlságosan bonyolultak.
Szeretnék egy olyan megoldást ami a lehető legoptimálisabban képes kiszolgálni ezt a tulajdonság kezelést, akkor is ha teljes szerkezet átalakítással jár.

előre is köszi az ötleteket
‹ plpgsql - recordset változóba mentése Két dátum közti intervallum ellenőrzése ›
 ■
1

Így ebben a formában

MadBence · 2013. Júl. 19. (P), 08.26
Így ebben a formában szerintem egy tulajdonság szűréséhez 1 join kell (illetve join az item-től a property-ig)

select * from item i

join item_property_value ipv1 on ipv1.item_id = i.item_id
join property_vale pv1 on pv1.property_value_id = ipv1.property_value_id
join property p1 on p1.property_id = pv1.property_id

join item_property_value ipv2 on ipv2.item_id = i.item_id
join property_vale pv2 on pv2.property_value_id = ipv2.property_value_id
join property p2 on p2.property_id = pv2.property_id

where p1.property_name = 'szín' and
(pv1.property_value_name = 'piros' or
pv1.property_value_name = 'kék') and
p2.property_name = 'súly' and
(pv2.property_value_name = '10kg' or
pv2.property_value_name = '20kg')
2

Ha jól értem, egy harmadik

Hidvégi Gábor · 2013. Júl. 19. (P), 09.01
Ha jól értem, egy harmadik tulajdonság kereséséhez már harmadik join kell; szerintem arra gondolt danmail, hogy ezt szeretné valahogy elkerülni.
3

igen igen. join-nal megkapom

danmail · 2013. Júl. 19. (P), 09.17
igen igen.
join-nal megkapom az eredményt, de ha mondjuk 10 paraméterre szeretnék keresni, akkor 10 join kell hozzá. Szerintem ez már nem annyira optimális sql :)
A tulajdonságok és tulajdonság értékek száma a keresésben teljesen változó lehet.
4

Lehet én értem rosszul?

csabessz47 · 2013. Júl. 19. (P), 11.10
De nincs ez túlbonyolítva?

SELECT *
FROM item i
  JOIN item_property_value ipv ON i.item_id = ipv.item_id
  JOIN property_value pv ON pv.property_id = ipv.item_id
  JOIN property p ON p.property_id = pv.property_id
WHERE
  pv.property = 'kék' AND
  pv.property = 'sárga' # aztán itt már annyi feltételt lehet összeciklusozni amennyi csak kell :)
ORDER BY p.property_name


Összekapcsolja az egészet, innentől kezdve csak a feltételekkel kell játszani
5

Ez így ebben a formában

MadBence · 2013. Júl. 20. (Szo), 01.00
Ez így ebben a formában biztosan nem jó, hiszen nem egy tulajdonságot kell vizsgálni, hanem többet. Ha mindegyik tulajdonságra pontos egyezést vizsgálnánk (tehát szín=piros és súly=10kg, nem pedig (szín=piros vagy szín=kék) és súly=10kg), akkor elég lenne egy join, trükkös group by / having-gel.

Ennek az általános leképzésnek a komplexitás az ára. Én mondjuk kivenném a property_value táblát, és item 1-* item_property_value *-1 property leképzést csinálnék (és a tulajdonság értéke a kapcsolótáblába kerül). Persze ha fontos, hogy a mezők milyen értékeket vehetnek fel, akkor megmarad a property_value tábla, én ekkor így csinálnám a leképzést:

item 1─* item_property_value *─1 property
                       *             1
                       │             │
                       1             │
                 property_value *────┘


Meg kell vizsgálni, milyen osztályhierarchiát próbálsz betuszkolni az adatbázisba, és a bonyolultság függvényében egy hatékony leképzést kell választani (amit most csinálsz, az kb ez).
7

Nem teljesen értem, hogy az

danmail · 2013. Júl. 21. (V), 17.37
Nem teljesen értem, hogy az értékek nevének a kapcsolótáblába kerülésével, hogy lesz könyebb a keresés. Nem a nevekre keresek hanem az id-kra
6

document alapú tárolás?

blacksonic · 2013. Júl. 20. (Szo), 11.26
Gondolkoztál dokumentum alapú tároláson? pl MongoDb?
sok JOIN le fogja ölni az adatbázist
8

Gondoltam rá, de mivel még

danmail · 2013. Júl. 21. (V), 17.42
Gondoltam rá, de mivel még nem vagyok bennük otthon nem akartam a fejlesztést a tanulás rovására tenni.
Ott ez az elképzelés sokkal járhatóbb? Végső soron ha kell áttérek mongora...
Le tudnád írni körülbelül azt a nosql lekérdezést ami azt az eredményt adja vissza amit én szeretnék?