Ja robiłem dokładnie identyczną strukturę. To było mneij wiecej tak (nie pamietam dokładnie, rok temu to pisałem

)
Utworzylem nastepujace tabele:
1. Kategorie (id, nazwa, grupy_cech)
2. GrupyCech (id,id_cechy,nazwa)
3. Cechy (id,nazwa,typ[tekst,link,plik,obrazek])
4. CechyWartosci (id,id_cechy,id_produktu,wartosc)
Nastepnie użytkownik mogl sobie pogrupowac cechy w grupy (zeby nie klikac dziesiatek aktegorii tych samych cech).
Przy tworzeniu nowych kategorii produktów użytkownik wybierał sobie po prostu kilka grup cech które mu były aktualnie potrzebne (select multiple) i dane o grupach cech wędrowały do pola "grupy_cech" zlączone przecinkami.
Przy dodawaniu produktu zostaly wyciagane grup cech produktów (przy użyciu FIND_IN_SET + paru innych warunkow) i wyswietlane dodatkowe pola. Nastepnie dane wędrowały do tabeli CechyWartości i stamtąd były pobierane przy wyswietlaniu na stronie.
Może nie było to najlepsze rozwiązanie, ale sprawdzalo sie idealnie - kazda kategoria produktów mogła mieć nieskonczienie wiele różnych grup cech, jak np. monitory mogly miec dane dotyczace monitorow, dyski dane dotyczące dysków twardych, ale oprocz tego te 2 kategorie mogły miec wspolne cechy, które nie miały inne kategorie. (http://sklep.komputronik.pl - najlepszy przykład w jaki sposób to działa. Nie jest to mój sklep ofcoz, ale moj skrypt umożliwiwał dowolne formowanie karty produktu pod względem wystepujących parametrów). Zaletą takiego rozwiązania jest, że tabela Produkty składała sie tylko z podstawowych pól jak ID, nazwa, kategoria, ew. cena.
Ech.. zawile to napisałem, ale jeszcze poranna kawa nie zaczęła działać