[baza] shema večjezične trgovine z opcijami

3 naročniki

Živjo,
malo za razmislek in za kakšno idejo/nasvet odpiram tole temo.
Spletnih trgovin je že veliko, zato delam jaz še eno :)

Funkcjonalnosti:
- večjezičnost,
- izdelek v več kategoirjah (ena kategorija je privzeta za breadcrumbse)
- proizvajalci
- opcije(atributi) izdelka, npr barva, velikost,....
- filtriranje izdelkov po kategorijah in iskanje glede na atribute
- različna cena, zaloga,.. glede na izbrano kombinacijo opcij

Tukaj je čisto osnovna, prva in precej okleščena verzija, kako naj bi baza zgledala. http://shrani.si/f/R/oZ/w2Jzqn5/capture.png

Primer podatkov:
product(artikel)
product2attribute(productid, attributeid, attributevalueid)
attribute(barva, velikost,..)
attribute_value(rdeca,rumena,S,M,L,XL,...)

Par zelo pomembni stvari, ki v tej shemi manjka:
- cena
- zaloga
- serijska št.
ob izbranih opcijah.

Vprašanje pa sledi:
Kako bi zapisali ceno, glede na to, da se lahko razlikuje glede na izbrano kombinacijo opcij.

Primer:
majica v rdeči barvi S = 9€
majica v zlati barvi S = 9€
majica v rdeči barvi M = 10€
majica v zlati barvi M = 15€

Torej, izbrana opcija ne more vedno povečati za fiksni ali procentualni znesek osnovne cene artikla.

Podobno vprašanje je, kako zapisati zalogo in serijske št. glede na izbrano kombinacijo večih opcij.

Edina ideja, ki mi pade na pamet je tabela vseh možnih permutacij pri urejanju vsakega artikla.

Primer:
velikost; barva; cena; serial; zaloga
S; rdeca; 9€; 123; 2
S; zlata; 9€; 123z; 0
M; rdeca; 10€; 1234; 0
M; zlata; 15€; 1234z; 3

Se spomni kdo kakšne drugačne rešitve?
Bi drugače zastavili bazo?
Bi bilo bolje vsako kombinacijo opcij zapisati kot svoj artikel z nekim parent_id-jem 'master' izdelka?

Vseh nasvetov in komentarjev bom zelovesel :)

edit:
zdaj ko sem še 1x prebral, se mi zdi najbolje zalogo in ceno zapisati v tabelo 'product' in vse artikle grupirati po polju 'model'... v tabelo 'product' pa dodati še eno polje za privzeto prikazani artikel.

Res je fajn toplo vodo odkrivat :D

Jaz bi jo takole:
http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-7-advanced-orm-entity-attribute-value

EAV is bad. Če ne prej boš to ugotovil, ko boš imel 1km joinov. Če ne verjameš pa poglej, kaj dela magento...

EAV ali vsaj nekaj podobnega je precej bolje kot pa nova tabela za vsako lastnost produkta kot je zgoraj :)

@SpinX: Kje si videl novo tabelo za vsako lastnost? Vse lastnosti so v eni tabeli 'attribute', vrednosti pa v 'attributevalue'. Pravzaprav je struktura precej podobna primeru, ki si ga poslal, ki mi je btw. dal za misliti. (različni tipi za attributevalue)

@krho: Je res 1km = bad, ampak a kaj drugega preostane? Konec koncev se lahko te zadeve pocachira in ob spremembah artikla/opicj zapiše v neko obliko, ki prihrani precej joinov. Poznaš mogoče kak drug pristop?

Včeraj nisem utegnil odgovoriti, bom pa danes zvečer naredil verzijo 2 strukture in poslal. Hvala za pomoč :)

document based storage vsaj za attribute, lahko tudi vse, kar ne potrebuje transakcij, Za ostalo relacijska baza.