Ukládání různých typů produktů do databáze

[horalhoralhora]

Potrebuji pomoct s rozhodnutim pro nasledujici zadani:

• 15 000 produktu
• 100 kategorii/typu, kazda kategorie vyzaduje vlastni skupinu produktovych vlastnosti (atributu)
• filtrovat produkty ve skupine podle zadanych atributu
• dve jazykove mutace

Hlavni pozadavky jsou:

• pridavat atributy produktu, bez nutnosti zmeny db schematu
• moznost filtrovat atributove vlastnosti produktu

Pro SQL-MariaDB, jsem dosel k nazoru, ze EAV reseni je "nejpohodlnejsi" a lehce skalovatelne pro budouci potreby pridavat dalsi produktove atributy. Ovsem co se vykonu tyce v pripade potreb filtrovani (v kontextu kategorie X), mam obavu, ze je to ten horsi zpusob.

Pro toto zadani se jevi jako vhodnejsi nerelacni databaze (Mongo), ktera by mela zadani i hlavni pozadavky lepe uspokojit v pripade, ze objekt typu produkt neni casto menen uzivateli. Preklady jednotlivych poli a doprovodnych textu bych ukladal primo do objektu typu "produkt".

Pro oba pripady by platilo predvytvoreni produktove stranky pro zakaznika v okamziku vytvoreni produktu. Produktova stranka by se pak doptavala na aktualni stav skladu.   

Dava v teto situaci smysl vydat se cestou nerelacni databaze? Nekdo kdo neco podobneho resil a podelil by se teorii iplementace?
 

[Reklama]

[Logik]

Jedno z možných a dobrých řešení je i SQL databáze + JSON typ na specifikace.
Na nerelační databázi se bude hůře dělat nějaké složitější filtrování a řazení.

[redustin]

Jen pozor u uvedené Maria DB - její JSON typ má (snad zatím) veliká omezení u indexů, protože neumí seznamový typ a virtuální sloupce, nad kterými se vytvářejí indexy, nemohou pocházet z JSON pole (vytáhne se a naindexuje pouze první prvek pole).

[RDa]

Potrebuji pomoct s rozhodnutim pro nasledujici zadani:

• 15 000 produktu
• 100 kategorii/typu, kazda kategorie vyzaduje vlastni skupinu produktovych vlastnosti (atributu)
• filtrovat produkty ve skupine podle zadanych atributu
• dve jazykove mutace

Hlavni pozadavky jsou:

• pridavat atributy produktu, bez nutnosti zmeny db schematu
• moznost filtrovat atributove vlastnosti produktu

Doporucuji se naucit alespon zaklady SQL a naprogramovat si to na aplikacni urovni. Alespon se naucite delat s databazemi, ktere jsou primo k tomuto urceny. Chapu ze dnes je moderni vse jen lepit z hotoveho, ale p*del vam taky neutira sluzebna.

Pro 15000 polozek muzete pouzit treba SQLite, pac objem dat vam vyjde mensi nez cache procesoru.

[horalhoralhora]

Chapu, ze jeden ze zakladu SQL je pevne stanovene schema. Kvuli pozadavku snadne rozsiritelnosti jsem zacal premyslet o nerelacni databazi. V pripade SQL bych mel misto EAV tabulky pouzit tabulku pro kazdou skupinu produktu nebo jednu velkou tabulku, kde jsou vsechny atributy. Existuje lepsi zpusob pro SQL?

[Reklama]

[Kit]

Jednoduchým řešením je vytvoření JSON se všemi nepovinnými atributy, uložit to do jednoho sloupce a vyhledávat fulltextem.

[RDa]

Chapu, ze jeden ze zakladu SQL je pevne stanovene schema.

A brani vam nekdo vytvorit tabulky:

Kód: [Vybrat]

Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu
?

Trocha premyslejte, vy "pevne schema".

[horalhoralhora]

Chapu, ze jeden ze zakladu SQL je pevne stanovene schema.

A brani vam nekdo vytvorit tabulky:

Kód: [Vybrat]

Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu
?

Trocha premyslejte, vy "pevne schema".

Omlouvam se za to "pevne schema". Myslel jsem tim ukladani hodnot atributu do sloupcu, ktere jsou jasne definovany ne na radku coz je pripad prave EAV tabulek. Cemu jsem se chtel vyhnout je

Kód: [Vybrat]

Produkty
AtributyProduktuMobilniTelefony
AtributyProduktuOsvetlovaciTechnika
atd...

U tohohle reseni

Kód: [Vybrat]

Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu

coz je EAV pokud jsem to spravne pochopil mam obavu z rychlosti filtrovani... proto tady resim jestli je vhodnejsi relacni nebo nerelacni databaze

[RDa]

U tohohle reseni

Kód: [Vybrat]

Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu

coz je EAV pokud jsem to spravne pochopil mam obavu z rychlosti filtrovani... proto tady resim jestli je vhodnejsi relacni nebo nerelacni databaze

Ono to ale optimalne popisuje vas sparse data model, takze nemejte obavy o vykon. Pokud hledate "attr like %x%", tak vam zadna databaze nevyjde jako vyslovene lepsi. S ohledem na mnozstvi dat ktere mate, se nejedna o nijak kriticke rozhodnuti jak to udelat - takze doporucuji si svuj dataset natahnout do toho EAV a udelat vykonnostni testy - pak zjistite, kolik lidi jste schopen obslouzit.

Cileni na vykon musi byt konkretizovano - at vite ceho chcete dosahnout. Po urcitou hranici si vystacite s pouzivanim DB jak jsou, ale jestli chcete dosahnou milisekundove latence pro hledani mnohamilionoveho datasetu, musi se na to jit samozrejme jinak.

[luvar]

U tohohle reseni

Kód: [Vybrat]

Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu

coz je EAV pokud jsem to spravne pochopil mam obavu z rychlosti filtrovani... proto tady resim jestli je vhodnejsi relacni nebo nerelacni databaze

Obavy by som nemal. “Premature optimization is the root of all evil”.

Osobne mam skusenost s PostgreSQL (a kus aj s MariaDB) a tam su optimalizacie na takej urovni, na akej sa databazam typu mongodb ani nesnivalo (minimalne pred tromi rokmi). Inak povedane, ak neexploitujete prave jednu konkretnu vec, specificky pripad, tak PostgreSQL vychadza lepsie, i ked musi robit "viac roboty".

Co sa tyka obav, tie smiesne pocty riadkov vojdu do ramky pri dnesnom serveriku (alebo mobile). Ak by bol problem s indexami (ze zapis netrva 4ms, ale 12 napriklad), tak odporucam skusit https://www.timescale.com/. Vie to rozdelit na rozne fyzicke tabulky. Kazda fyzicka tabulka ma vlastne indexy, moze mat vlastny tablespace (fyzicky disk) a podobne.

PS: Navrhujem skusit si spravit prototyp v postgresql, mariadb a aj v mongo. Nie viac prace ako na jeden den (springboot a jedo automagic). Minimalne naplnenie dat (vygenerovat data sa daju pekne cez jqwik napr) a nasledne pokusne selekty sa urcite daju dat do dna pre vsetky tri technologie (nakolko staci zmenit connectionstring vpodstate). Samotne "vytunenie" jednotlivych technologii moze zmenit poradie, ale imho zistite, ze casy su absolutne OK a netreba riesit (vzdy zalezi ale na hw).

[horalhoralhora]

U tohohle reseni

Kód: [Vybrat]

Produkty
Kategorie
Atributy
AtributyKategorii
AtributyProduktu

coz je EAV pokud jsem to spravne pochopil mam obavu z rychlosti filtrovani... proto tady resim jestli je vhodnejsi relacni nebo nerelacni databaze

Ono to ale optimalne popisuje vas sparse data model, takze nemejte obavy o vykon. Pokud hledate "attr like %x%", tak vam zadna databaze nevyjde jako vyslovene lepsi. S ohledem na mnozstvi dat ktere mate, se nejedna o nijak kriticke rozhodnuti jak to udelat - takze doporucuji si svuj dataset natahnout do toho EAV a udelat vykonnostni testy - pak zjistite, kolik lidi jste schopen obslouzit.

Cileni na vykon musi byt konkretizovano - at vite ceho chcete dosahnout. Po urcitou hranici si vystacite s pouzivanim DB jak jsou, ale jestli chcete dosahnou milisekundove latence pro hledani mnohamilionoveho datasetu, musi se na to jit samozrejme jinak.

Dobre. Pokud by tedy schema vypadalo napriklad nejak takto:

Kód: [Vybrat]

produkt[id]
atributy[id,nazev,hodnota]
hodnotyAtributu[id,id_atribut,hodnota]
atributyProduktu[id, produkt_id, id_atribut, id_hodnota]

je lepsi pro kazdou hodnotu, ktera muze byt ulozena v "hodnotyAtributu"  definovat vsechny pouzite datove typy?
tzn. hodnotaString[string],hodnotaInt[int],hodnotaDouble[double] atd...

[Ondrej Nemecek]

Ledaskdo považuje EAV za antipattern. Řešilo se tu na fóru už několikrát. Zároveň platí, že alespoň jednou si každý EAV musí vyzkoušet. Podle mě je nejlepší použít NoSQL možnosti SQL databází - json nebo xml typy mají databáze indexované takže to je rychlé a současně se to dobře používá.

[RDa]

je lepsi pro kazdou hodnotu, ktera muze byt ulozena v "hodnotyAtributu"  definovat vsechny pouzite datove typy?
tzn. hodnotaString[string],hodnotaInt[int],hodnotaDouble[double] atd...

Zde si odpovez podle toho, zda mas vyhledavaci dotazy striktne typovane, tj. od uzivatele zadane vstupy ve forme "12300", 0x300C a 1.23e4 jsou doplneny typy (string, int, double), podle kterych budes provadet typove korektni hledani. Celkem pochybuji ze ano, takze by sis mohl vystacit se stringy.

Tip na inspiraci: v jedne me aplikaci se pracuje s fyzikalnimi jednotkami u tech atributu a to vcetne SI predpon (napr. 4.7kΩ), takze mam ulozeno vse v rozparsovane forme - tj. normalizovanou hodnotu (double, 4.7e3) + zvlast nasobek (k) a zvlast jednotku (Ω, v atributu), normalizace hodnoty je kvuli spravnemu serazeni. Pri zobrazeni generuje human readable hodnota (string) dynamicky, pri hledani se vstup rozparsuje na onu normalizovanou formu. Podle toho, jaka to je jednotka se tedy i urci spravna mnozina atributu.

[user398]

U variantov produktov je problem napriklad ako ukladat cenu daneho variantu produktu.

Povedzme ze mame produkt tricko (base price 10€) s atributmi: velkost (s, m, l, xl), farba (green, blue, red) a potlac (ano, nie), pricom niektore atributy nam mozu ovplyvnovat aj zakladnu cenu (velkost XL +5€, farba blue +5€, potlac ano +10€). Takze mame dokopy 24 moznych kombinacii s roznou vyslednou cenou:

Kód: [Vybrat]

s, green, ano(+10) = 20€
s, green, nie = 10€
s, blue(+5), ano(+10) = 25€
s, blue(+5), nie = 15€
s, red, ano(+10) = 20€
s, red, nie = 10€
m, green, ano(+10) = 20€
m, green, nie = 10€
m, blue(+5), ano(+10) = 25€
m, blue(+5), nie = 15€
m, red, ano(+10) = 20€
m, red, nie = 10€
l, green, ano(+10) = 20€
l, green, nie = 10€
l, blue(+5), ano(+10) = 25€
l, blue(+5), nie = 15€
l, red, ano(+10) = 20€
l, red, nie = 10€
xl(+5), green, ano(+10) = 25€
xl(+5), green, nie = 15€
xl(+5), blue(+5), ano(+10) = 30€
xl(+5), blue(+5), nie = 20€
xl(+5), red, ano(+10) = 25€
xl(+5), red, nie = 15€
Ak varianty priradujeme k produktu naivne, napriklad takouto tabulkou ProductVariants:
FK product_id: 123 (->tricko)
FK attribute_id: 456 (->velkost)
FK atribute_value: 789 (->XL)
price: +5

tak mame minimalne 2 problemy:
1. nevieme pokryt vsetky mozne kombinacie cien, ale len tychto 24. Ak nejakej hodnote atributu priradime cenu (potlac ano = +10€) tak sa objavi vo vsetkych kombinaciach kde atribut vystupuje. Lenze marketing bude chciet pre kombinaciu atributov potlac s modrou farbou (lubovolna velkost) len +5€ miesto +10€ za potlac, pretoze potlac na modru farbu je lacnejsia ako na ine...
2. Aku cenu zobrazovat v product listingu ked si user prechadza kategorie? Logicky najmensiu, ale nemozeme tam dat automaticky cenu base produktu (10€) pretoze ak produkt ma iba take atributy ktore zvysuju cenu tak najnizsia cena nemusi byt rovnaka ako cena base produktu. Za toto pokutuje napriklad Google ak chcete byt v nejakych jeho feedoch. Musite zobrazovat cenu za aku si to moze zakaznik kupit. Urobit SQL na product listing ktory dynamycky prepocitava ceny podla atributov a vybera najnizsiu (+ rozne ine filtre ktore si user moze naklikat) je pre SQL masiny nemozne v relanom case s realnymi resourcami. Nam to davalo cca 10-30 sekund na request.
3. Su mozne este vylepsenia ze nejaky atribut moze cenu aj znizovat...

Alebo mozeme tieto vsetky mozne kombinacie atributov ukladat zvlast pod vlastnym ID a pokladat to za samostanty produkt, takze miesto jedneho tricko produktu budeme mat max 24 produktov. To je fajn pretoze mame volnost nastavovat lubovolnej kombinacii atributov lubolne ceny. Ak nejaka kombinacia atributov nedava zmysel tak ju neuvedieme (tricko velkosti S s lubovolnou farbou nevieme vyrobit s potlacou lebo sa nam nezmesti na plochu tricka) takze budeme mat menej zaznamov (24 - 3 = 21). SQLka su jednoduchsie, na ukor duplikacie dat v DB. Ale mame aj problemy:
1. Narastie pocet zaznamov v DB. A moze aj extremne. U zlozitych produktov s vela atributmi, pricom tie atributy mozu mat vela roznych hodnot mozeme dostat az milion kombinacii pre jeden produkt. Co ked mame takychto produktov vela?
2. Zlozitejsia administracia. Editor musi vediet nastavit davkovo ceny pre rozne kombinacie atributov, pretoze nechce zadavat manualne vsetky kombinacie, ale zas musi vediet nastavit ked chce aj lubovolnu moznu kombinaciu. OK, u toho tricka s max 24 kombinaciami mozeme zobrazit maticu input boxov ale co ten produkt s milion kombinaciami?

Okrem ceny sa samozrejme k jednotlivym variantom ukladaju aj ine udaje, napr. skladove zasoby. Modrych triciek velkosti XL mam na sklade ine mnozstvo ako cervenych L. Musim vediet vypinat docasne niektore kombinacie atributov,...

Ak vysledkom ma byt tzv faceted search tak by som zvazil pouzit kombinaciu SQL DB + ElasticSearch/Solr. Pri administracii zapisujem do SQL a potom synchronizujem do ES. ES je perfektny na product listing, ked si user filtruje podla roznych parametrov (product name obsahuje 'Adidas' (fulltext), velkost L, modra farba, cenova hladina 10-20€, kategoria 'Panske tricka', na sklade). S ElasticSearchom dostavame response v milisekundach.

EAV pouziva napr. Magento ale tiez maju tzv flatten tabulky, pretoze EAV je moc kosate a rozumny product listing nad tym neurobis. Plus samozrejme tiez tam ide pouzit NoSQL na zrychlenie.

[Kit]

U variantov produktov je problem napriklad ako ukladat cenu daneho variantu produktu.

Povedzme ze mame produkt tricko (base price 10€) s atributmi: velkost (s, m, l, xl), farba (green, blue, red) a potlac (ano, nie), pricom niektore atributy nam mozu ovplyvnovat aj zakladnu cenu (velkost XL +5€, farba blue +5€, potlac ano +10€). Takze mame dokopy 24 moznych kombinacii s roznou vyslednou cenou:

V OOP bychom to vyřešili vzorem Decorator. Možná by se to dalo vyřešit uložením serializovaného objektu. Nevýhodou tohoto řešení je však prakticky nemožná indexace, proto se jako efektivnější jeví vytvoření jednoho objektu a vygenerování všech 24 variant, které jsou následně uloženy do databáze.