Ograniczenia dostępnych kombinacji opcji

Witam
Mam taki model. Produkt zawiera opcje (od 4 do 6) typu kolor, grubość itp. Opcje zawieracją wartości (od 2 do 30). Dostępne wartości opcji dla produktu są zależne od siebie. Czyli Produkt 1 ma kolory zielony, czerwony, niebieski i dla zielonego i czerwonego dostępne są grubości 0.5 i 0.6 a dla niebieskiego 0.5, 0.6 i 0.45.

opcje się zmieniają, wartości się zmieniają, same ograniczenia też się zmieniają.

Jak to zamodelować i obsłużyć w jakiś mądry sposób? Aktualnie mam tabelę ze wszystkimi kombinacjami wartości opcji dla poszczególnych produktów i flagę Aktywy, która wyłącza dostępność kombinacji wartości opcji, ale sam wiem, że jest to badziewne i ciężkie do utrzymania (dodanie opcji zmienia format tabeli z ograniczeniami).

Jakieś pomysły?

Jest trzy rozwiązania:

1. Trzymasz listę możliwych kombinacji
2. Trzymasz listę zabronionych kombinacji
3. Opcje są wielopoziomowe.

Najpierw powiedz po co chcesz to robić, to wtedy będzie można wymyślić dobre rozwiązanie. Jaki jest cel?
Po przeczytaniu nie do końca jestem pewien, czy chodzi ci o diagram uml, scheme do bazy danych, sposób reprezentacji tego w pamięci, sposób reprezentacji tego w pliku, ktory bedziesz czytał, łatwą konfigurację z poziomu kodu źródłowego, etc.

To teraz tak mam. Trzymam listę wszystkich kombinacji w tabeli z polami KolorId, GruboscId, PowlokaId, ....
Problem, że jak dochodzi nowa opcja to trzeba zmienić format tabeli (dodać kolumnę z opcją). Myślałem, żeby trzymać kombinacje id wartości w jakimś łańcuchu 1-2-3 ale jakoś mi się nie podoba ten pomysł.

Wielopoziomowość odrzuciłem na początku. Logicznie opcje nie są zależne od siebie zależne są tylko wartości w sensie ograniczenia kombinacji.

nalik napisał(a):

Najpierw powiedz po co chcesz to robić, to wtedy będzie można wymyślić dobre rozwiązanie. Jaki jest cel?
Po przeczytaniu nie do końca jestem pewien, czy chodzi ci o diagram uml, scheme do bazy danych, sposób reprezentacji tego w pamięci, sposób reprezentacji tego w pliku, ktory bedziesz czytał, łatwą konfigurację z poziomu kodu źródłowego, etc.

Klient zamawia produkt, pokazuje mu się okno, w którym określa wartości opcji produktu (Kolor, grubość, powłoka itp). niektóre produkty nie występuja w różnych kombinacjach. Chodzi o to, żeby klientowi pokazywać tylko te wartości opcji do wyboru, które są możliwe. Produkty mają różną ilość opcji (edytory są tworzone dynamicznie).

Czyli wybieram Kolor i ładują mi się dostępne grubości i powłoki, potem wybieram grubość i dla wybranego koloru i grubości ładują mi się dostępne powłoki.

Potrzebuje schematu bazy. Opcja to jest klasa Opcja w Wartosc to jest klasa Wartosc. Opcje zawierają wartości. Do tego potrzebuje metody przechowywania w DB schematu ograniczeń (maksymalnie elastycznego) oraz pomysłu na obsługę tego w aplikacji (asp.net mvc).

KodSlownikaA, IdSlownikaA, KodSlownikaB, IdSlownikaB
Wpisuj tylko zabronione kombinacje.
KodSlownikaA
0 - Kolor
1 - Grubość
2 - Powloka

Po prostu trzymać dostepne opcje:

CREATE TABLE product (
    id INTEGER PRIMARY KEY AUTO_INCREMENT, 
    name TEXT NOT NULL);
    
CREATE TABLE prod_options (
    id INTEGER PRIMARY KEY AUTO_INCREMENT,
    prod_id INTEGER,
    color VARCHAR(100) NOT NULL,
    thickness INTEGER NOT NULL,
    field INTEGER NOT NULL,
    CONSTRAINT UNIQUE (id, prod_id, color, thickness),
    FOREIGN KEY (prod_id) REFERENCES product(id) ON DELETE CASCADE
);
 

Klient wybiera produkt -> jeden select;
Klient wybiera kolor -> drugi select uzywajacy produktu z poprzedniego selecta,
Klient wybiera grubosci -> trzeci select uzywajacy wartoscidwoch poprzednich
i tak z kolejnym ograniczeniem

Dzięki za odpowiedzi.
Nalik i Dragon, ja mam coś takiego obecnie (ten system działa tylko szukam bardziej elastycznego rozwiązania).
Problem z Waszymi propozycjami jest taki, że w przypadku gdy dojdzie nowy produkt i będzie on miał jakąś inną opcję (np. Wysokość) to do tabeli z ograniczeniami trzeba będzie dodać kolumnę czyli zmienić schemat bazy danych i tego chcę uniknąć (już raz mi się tak zdarzyło w okresie wdrażania aplikacji).
Chyba zostanie tak jak jest na razie bo wasze propozycje są tożsame z moim rozwiązaniem.
Docelowo myślałem o rozwiązaniu, które nie będzie potrzebowała zmiany schematu tabeli z ograniczeniami w przypadku pojawienia się nowych opcji.

Zastanawiałem się kiedyś nad czymś takim

Produkt {int Id, string Nazwa}
OgraniczenieOpcji {int Id, int ProduktId, bool aktywne} - nagłówek ograniczenia
DefinicjaOgraniczenia {int OgraniczenieOpcjiId, int OpcjaId, int WartośćOpcjiId} - definicja ograniczenia, lista wartości opcji

OgraniczenieOpcji zawiera listę DefinicjaOgraniczenia (wartości opcji) czyli mamy drzewo. OgraniczenieOpcji dla produktu może zawierać dowolną ilość wartości opcji.

Tylko to jest trudniejsze w obsłudze zarówna dla aplikacji jak i użytkownika.

To może baza typu NoSql

W pierwszym momencie też zrobiłem coś podobnego do twojego pomysłu. Ale potem zacząłem pisać zapytanie wstawiające i sprwdzajace opcje i zobaczyłem na ile zapytan sie to rozkłada.

NoSQL raczej odpada. Cała aplikacja (i jeszcze kilka innych u klienta) działa na SQL Serwerze.