Jestem w trakcie tworzenia sklepu. Jednym z założeń jest możliwość przypisania do produktu wielu cech, np. może być produkt: Pamięć USB firmy XYZ

W ramach tego produktu mogę wybrać:
1. Pamięć USB firmy XYZ o pojemności 16GB kolor biały z nadrukiem - stan magazynowy 20szt
2. Pamięć USB firmy XYZ o pojemności 16GB kolor biały bez nadruku - stan magazynowy 50szt
3. Pamięć USB firmy XYZ o pojemności 16GB kolor czarny z nadrukiem - stan magazynowy 10szt
4. Pamięć USB firmy XYZ o pojemności 16GB kolor czarny bez nadruku - stan magazynowy 5szt
5. Pamięć USB firmy XYZ o pojemności 16GB kolor niebieski z nadrukiem - stan magazynowy 41szt
6. Pamięć USB firmy XYZ o pojemności 16GB kolor niebieski bez nadruku - stan magazynowy 11szt

7. Pamięć USB firmy XYZ o pojemności 32GB kolor biały z nadrukiem - stan magazynowy 10szt
8. Pamięć USB firmy XYZ o pojemności 32GB kolor biały bez nadruku - stan magazynowy 17szt
9. Pamięć USB firmy XYZ o pojemności 32GB kolor czarny z nadrukiem - stan magazynowy 3szt
10. Pamięć USB firmy XYZ o pojemności 32GB kolor czarny bez nadruku - stan magazynowy 8szt
11. Pamięć USB firmy XYZ o pojemności 32GB kolor niebieski z nadrukiem - stan magazynowy 29szt
12. Pamięć USB firmy XYZ o pojemności 32GB kolor niebieski bez nadruku - stan magazynowy 70szt

dodatkowo każdy produkt może przynależeć do jednej lub kilku kategorii.

Czy macie pomysł jak to od strony bazy rozwiązać?
Za wszelkie podpowiedzi będę ogromnie wdzięczny, ponieważ głowię się nad tym jakiś czas i nie wiem od której strony to ugryźć.

Ja bym to zrobił tak:

Pamięć USB xxYYZZ - produkt główny
- Pojemność 16GB
- Pojemność 32GB
Jako warianty produktu (czyli normalny produkt ale z ID produktu bazowego np. w kolumnie variant

- biały z nadrukiem/bez
- czarny z nadrukiem/bez
To jako cechy przechowywane w oddzielnej tabeli i połączone relacją n:n z wariantem

Zasada jest taka że nie możesz kupić produktu głównego, tylko wariant z określoną cechą.

To będzie 3 tabelki: products (id, nazwa, variant (default NULL lub ID produktu głównego) , options (ID, name), product_option (product_id, option_id)

Do tego oczywiście tabele z kategoriami: categories(id, name), category_product(category_id, product_id)

Możesz też przechowywać ID kategorii głównej w samym produkcie, albo oprzeć całość o category_product

Nie wiem czy dobrze łapię, ale wydaje mi się, że:

a) nie mysql, tylko mongo, wrzucasz wtedy sobie różnie ustrukturowane produkty i sie schemą nie przejmujesz

w mysql tworzysz tylko krotkę Produkt(id), a potem masz do niej relację 1:n krotek Cecha(id_produktu, key, value). Mało to wydajne, ale elastyczne. Wtedy możesz mieć:

Produkt(1):
- Cecha(1, 'nazwa', 'pamięć usb bla bla bla')
- Cecha(1, 'typ', 'pamięć')
- Cecha(1, 'podtyp', 'usb')
- Cecha(1, 'pojemność', '10GB')
- Cecha(1, 'nadruk', true)

Produkt(2):
- Cecha(2, 'nazwa', 'pamięć usb bla bla bla')
- Cecha(2, 'typ', 'pamięć')
- Cecha(2, 'podtyp', 'usb')
- Cecha(2, 'pojemność', '32GB')
- Cecha(2, 'nadruk', false)

itd.

Jak dla mnie cholernie rakotwórcze rozwiązanie, ale to chyba dość popularna technika symulowania nieschematycznych danych na relacnych bazach

Dzięki za pomoc i wskazówki, coś się w głowie otworzyło

Pyton_000 patrzę tak na to Twoje rozwiązanie, i mi 4 tabelki wychodzą
produkt (id, nazwa)
wariant(id,id_produktu,nazwa,cena,magazyn)
cecha(id,nazwa)
cecha_produkt(id_cechy, id_produktu, wartosc)

?

uirapuru niestety Mongo dotychczas nie dotykałem a tym bardziej złączyć to z mysql będzie dla mnie kłopotliwe.

3, wariant jest umieszczany w tej samej tabeli co produkt tyle że jest kolumna dodatkowa dla wariantu (rozpisane w poprzednim po,ście)

4. kolejny wariant to jedna kolumna w której przechowujesz zserializowany obiekt/array z cechami konkretnego produktu. minus jest taki, ze nie idzie po tym wyszukiwać

Dzięki Wam. Przejdę przez oba rozwiązania, któreś się przyjmie.