Pomysł bazy na katalog produktów w sklepie int., Z wieloma kategoriami Opcje

[MOniToR]

Witam
Byłbym wdzięczny jeżeli ktoś by mi podsunął jakiś dobry pomysł na zaprojektowanie tabel(jakich i ile) dla katalogu produktów sklepu, z wieloma kategoriami. Chodzi mi to żebym mógł dodawac nowe kategorie produktow razem z ich właściwościami i żeby nic nie było ograniczone. Mam nadzieje, że w miare jasno przedtsawiłem o co mi chodzi, z góry dzieki za pomoc.

[mike]

Nic trudnego.
W najpostrzej postaci to trzy tabele: Products, Categories, ProductsCategories (tabele łącząca wiele do wielu)

Products
id | name | jakieś atrybuty

Categories
id | name | jakieś inne atrybuty

ProductsCategories
id_product | id_category

Ostatnia tabela łączy produkty z kategoriami, tak że każdy produkt może należeć do wielu kategorii i jednocześnie jedna kategoria może zawierać wiele produktów.

Rozbudowa jest łatwa.
Jak chcesz drzewo kategorii to robisz:

Categories
id | id_parent | name | jakieś inne atrybuty

gdzie id_parent to identyfikator kategorii nadrzędnej

[MOniToR]

no tak ale musze przeciez jeszcze dac opis produktow, ktory dla każdej kategorii bedzie inny i bedzie sie skladal z ilusc tam czesci i wlasnie z tym mam problem.

[ikioloak]

Musisz tylko rozbudowac lekko to co ci dam mike_mech:

ProductsCategories
id_product | id_category | opis

[MOniToR]

eh ale to nie jest jaksi tam prosty opis, opis produktu składa się z wielu informacji, które musza byc wyświetlone osobno w formularzu do dodawania produktu.

[mike]

~MOniToR wykaż inicjatywę i pomyśl trochę.

To co Ci podalem to niezdbędne minimum do tego żeby stworzyć konstrukcje o której wpominałeś.

Nic nie stoi na przeszkodzie żebyć dodawał do tabel kolejne pola, które moga być jakimiś artybutami w stylu: opis, waga, cena, ...

Najważniejsze są tylko elementy które podałem.

Zresztą spójrz na górę i zauważ że miejscami napisałem: "akieś inne atrybuty" To właśnie tutaj soebi możesz dać co tylko chesz.

[spenalzo]

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ć

Ten post edytował spenalzo 1.02.2006, 09:45:19