Pomoc z katalogiem produktów w sklepie

Witam.

Obecnie w pracy projektujemy aplikację webową, która pomaga w obsłudze hurtowni sprzętu sanitarnego. Jesteśmy na etapie projektowania bazy danych i napotkaliśmy pewien problem, który nam nieco pokomplikował sprawę. Może macie podobne doświadczenia z zagadnieniem tego typu i moglibyście doradzić coś ciekawego?

Mamy produkt katalogowy P i związaną z nim tabelę Produkt.
Każdy produkt posiada pewne cechy wspólne, np. kolor, wysokość, szerokość itp. Posiada także cenę.

Niestety jak to zazwyczaj bywa takie produkty mogą być sprzedawane w różnych konfiguracjach. Np. kabina prysznicowa może mieć różne rodzaje szyby (zwykła, falowana, przyciemniana itp.). Takie zmiany wpływają najczęściej na cenę. Niestety nie możemy tego rozwiązać na zasadzie: "Dodaj ekstra koszt za każdy bajer z konfiguracji", gdyż czasami szczególna konfiguracja może mieć inną cenę niż wynikałoby to z sumay poszczególnych bajerów w niej zawartej.

Przykład: wanna może być w konfiguracji z nóżkami i kranem.
wanna = 100 Euro
2 nóżki = +20 Euro
4 nóżki = +30 Euro
Kran złoty = +30 Euro
Kran srebrny = +20 Euro

Jeśli jedna z wybranych konfiguracji będzie przykładowo taka:
Wanna + 2 nóżki + złoty kran to zapłacimy za nią 150 Euro (ta cena jest wpisana w Systemie na stałe dla takiej konfiguracji!)
Ale firma sprzedająca wanny chce np. sprzedawać jak najwięcej nóżek więc robi super konfigurację
Wanna + 4 nóżki + Kran złoty = 140 Euro, a nie 160 Euro.... Stwarza nam to nie lada problemy.

Tak więc chcemy uzyskać rozwiązanie gwarantujące dużą elastyczność i gwarantujące mało zbędnych danych przechowywanych w bazie oraz uniknięcie redundancji. Wymagania można streścić następująco:

1. Niektóre produkty (nie wszystkie) mogą posiadać kilka opcji/konfiguracji
2. Ilość cech w konfiguracji nie jest ustalona na stałe i zależy od rodzaju produktu
3. Ilość wartości cech zależy od produktu i cechy (np. kran może być w konfiguracji KOLOR={złoty, srebrny}, ale wanna może być w konfiguracji KOLOR={Czerwony, biały})
4. Musimy unikać błędnego wpisywania konfiguracji (czyli opisywanie ręcznie konfiguracji nie wchodzi w grę)
5. Konfiguracja wpływa na cenę, ale nie rządzi się to żadnymi ustalonymi prawami. Może być np. tak, że wybór koloru nie wpływa na cenę (ale np. zakup koloru METALIC może już mieć znaczenie :P)
6. Z punktu widzenia osoby wybierającej konfigurację najlepszym wyjściem jest prezentacja wszystkich cech konfiguracji z możliwością wybrania ich wartości z jakichś ComboBoxów.
7. Jak za rok dany produkt nie będzie dostępny w takiej konfiguracji to nie może to mieć wpływu na produkty, które zostały już w takiej konf. zakupione

Hhhhhmm to chyba tyle. Może macie jakieś pomysły bo my przeprowadziliśmy dzisiaj burzę mózgów i każde z naszych rozwiązań miało spore wady. Czasami takie spojrzenie z zewnątrz + doświadczenie może sprawić, że dla Was rozwiązanie jest trywialne :-) Mam nadzieję, że ktoś taki się znajdzie :P Naszych rozwiązań celowo nie zamieszczam, aby się nikt nie sugerował. Mam nadzieję, że to rozumiecie.

Z góry dzięki za poświęcony czas!

P.S. To naprawdę dla mnie ważne bo jestem mocno odpowiedzialny za ten projekt, a już nie mam pomysłów :-)

no to jak ulał pasuje tu schemat dla faktur, tj tabela master - id konfiguracji, czas trwania, nazwa, cena, inne i tabela pozycje id konfiguracji, id pozycji, lp, towar, sztuk

co do wybierania kolorów itp to bym proponował (nie wiem jak to macie teraz zrobione dla pojedynczego towaru z np. różnym kolorem) dodatkowymi tabelami - cechy wartości

czyli mamy
towar
*id_towaru
nazwa

cecha
*id_cecha
#id_towar
nazwa

wartość
*id_wartość
#id_cecha
wartość

i np. dla wanny mamy kolor (biały, czerwony) kształt (prostokątna, kwadratowa) to zapiszesz to tak

towar
1 | wanna

cecha
1 | 1 | kolor
2 | 1 | kształt

wartość
1 | 1 | biały
2 | 1 | czerwony
3 | 2 | prostokątna
4 | 2 | kwadratowa

taka struktura pozwala na dodanie dowolnej ilości cech o dowolnej ilości wartości do każdego towaru. Jedyna wada to redundancja danych przy podobnych cechach - np. kran ma kolor (biały, czarny) a wanna (biały, czarny, zielony) to biały i czarny trzeba wpisać dwa razy. No ale albo uniwersalna struktóra albo mała baza - nie ma złotego środka

Ew. zamiast tabel z cechami i wartościami można dla każdej kombinacji cech tworzyć osobny zestaw ale to raczej mija się z celem.

A cha wyznacznikiem nowego zestawu jest oprócz poszczególnych elementów i ich ilości również cena całego zestawu - zestaw, którego cena jest większa bo kolor to metalic powinien być stworzony jako nowy zestaw. Ew w tabeli z wartościami możesz dodać pole dodatkowa_opłata (czy coś takiego) i np. dla

2 | 1 | czerwony metalic | 20

co będzie oznaczało, że wanna w zestawie pierwszym o kolorze czerwony metalic to dodatkowo 20zł

7 nie rozumiem :/

BTW napisz co wymyśliliście :)

Nasze rozwiązanie jest niemalże identyczne, lecz dołożyliśmy tabelę KONFIGURACJA łączącą Towary i Cechy. Tabela ta zawiera informacje o cenie dla każdej indywidualnej konfiguracji zapisanej w systemie. Tabela Cecha zawiera klucz obcy od Konfiguracji, aby można było określić jakie cechy zostały wybrane w ramach naszej konfiguracji. Reszta tak samo jak u Ciebie :-) Rozwiązanie faktycznie wydaje się być najabrdziej elastyczne, lecz męczy mnie ta redundancja bo jak będą dwie różne szafki z możliwością 100 kolorów każda to będziemy mieli 100 niepotrzebnych wpisów... zagmatwane to :P

taką redundancją bym się nie przejmował - w końcu tabela nie ma 50 pól które są powtarzane

No co racja to racja, ale nasz klient ma dużo różnych pomysłów, więc boje się, że może to zaowocować komplikacjami w przyszłości :-)

ale co ma klient do struktury bazy?

No on nie wie jak baza wygląda, ale ciągle ma jakieś pomysły dotyczące funkcjonalności, które wpływają na sposób przechowywania danych. To długa historia i nie na to forum ;-) Koniec końców, chyba się zdecydujemy na takie właśnie rozwiązanie.

skąd ja to znam :p