Witam,

Już jakiś czas zastanawiam się nad rozwiązaniem problemu z siatka cen do produktów.

Mam sobie program, który ma służyć do obliczania cen za poszczególne przedmioty (meble),
lecz ich ceny zależne są od wymiarów - dajmy na to jednej ścianki.

I tak oto mam od firmy zlecającej całą tabelkę z cenami np:




Tutaj mam jeszcze tabele z cenami w zależności od kroju itp, ale jak uporam się z sama ideą
dla tej bazy danych będzie już ok.

Mam zatem pytanie, jak umieścić takie tabele z cenami w bazie danych i jak składać zapytania
SQL, aby wyciągnąć informację ile kosztować będzie ścianka o wymiarach np. 527x780
(wymiary mieszczą się w szerokości 500-600 i wysokości 701-800, czyli cena XYX,
tylko jak to sprawdzić zapytaniem jednym?)

Myślałem nad stworzeniem tabeli, gdzie zamiast wymiarów WxH, byłyby wpisane maksymalne pola,
lub obwody danych elementów, ale nie wiem czy to dobre rozwiązanie, może ktoś z was ma inne.

Musi być również możliwość wygenerowania pełnej siatki cen w formacie jaki podałem wyżej, czyli
info o W i H powinny gdzieś być zaszyte.

Musze brać pod uwagę również fakt iż, ceny mogą się zmieniać i muszę mieć łatwy sposób ich aktualizacji
(zmieniać mogą się pojedyncze wartości, lub na zasadzie ALL +20%).

Z góry wielkie dzięki za informacje

Masz już zrobioną tabelę w MySQL z cennikiem? Jeśli tak to pokaż strukturę.

No właśnie zadałem pytanie, czy ktoś z was ma pomysł jak ja zaprojektować, bo nie mam za bardzo pomysłu jak ułożyć optymalną strukturę dla tego cennika...

Aha, przepraszam. Myślałem, że pytasz już o gotowe zapytanie

Jeżeli ceny nie są związane żadnym wyrażeniem arytmetycznym, to ja bym zrobił coś na ten kształt

[MYSQL] pobierz, plaintext 
tabela dimension_ranges
 
id (klucz PRIMARY) | cm_max [liczba]
[MYSQL] pobierz, plaintext 

[MYSQL] pobierz, plaintext 
tabela prices
 
id (klucz PRIMARY) | width_range (klucz obcy na dimesion_ranges.id) | height_range (klucz obcy na dimesion_ranges.id) | price [ d.e.c.i.m.a.l  - wykrppkowuję, bo dziwne rzeczy się dzieją o0]
[MYSQL] pobierz, plaintext 

I przykładowe dane:

dimension_ranges:
1 | 600
2 | 700
3 | 800
4 | 900

prices:
1 | 1 | 1 | 150
2 | 2 | 1 | 326
3 | 3 | 1 | 489
4 | 4 | 1 | zzz
5 | 1 | 2 | 389
6 | 2 | 2 | 489
7 | 3 | 2 | 550
8 | 4 | 2 | zzz

itd.

Musiałby zostać nałożony warunek unikalności grupowej width_range i height_range.

Ten przykład zakłada, że te przedziały będą równe dla wysokości i szerokości. Jeśli nie, to musisz zrobić drugą tabelę z przedziałami lub dodać określenie w istniejącej, której współrzędnej dotyczą.

Ok, pomysł wyglada sensownie, ale co w przypadku, kiedy siatek mam kilka różnych (jedna dla np, ścian z drewana inna dla ścianek ze szkła itp?)

dimention_ranges zostawiłbym i tam wartosci byłyby co 50 jednostek wpisywane

z kolei prices to pewnie osobne tabele dla różnych siatek np. prices_wood, prices_glass etc.

Jak z kolei wyswietlić cene dla konkretnego elementu, jesli mam wymiary W=550 i H=780?

Ewentualne inne przyklady?

Wiesz co, chyba wymyśliłem proste i fajne rozwiązanie.

Tabela prices:

id - integer, PRIMARY
width_max - integer
height_max - integer
price - decimal
item_id - integer // klucz obcy na tabelę z obiektami, których dotyczy cennik


width_max i height_max to wartości krańcowe zakresu. Proponuję takie zapytanie do wybierania danych:

[SQL] pobierz, plaintext 
SELECT price FROM `prices`.`prices` WHERE item_id = [tutaj identyfikator obiektu] AND width_max > [tutaj szerokość] AND height_max > [tutaj wysokość] ORDER BY width_max ASC, height_max ASC LIMIT 1
[SQL] pobierz, plaintext 

Nierówności mogą być ostre lub nieostre. Zrobiłem nieostre, bo dla np. obiektu o wymiarach 600 x 520 lepiej by trafił on do przedziału [600-700] x [500-600] niż [500-600] x [500-600]. Nazwa _max może być trochę myląca, bo chodzi o przedział niedomknięty. Jednak lepiej w bazie zawrzeć maksimum przedziału niż minimum, bo dla bardzo małych obiektów znajdzie ci cenę z najmniejszego przedziału, a dla zbyt dużego nie zwróci nic i o to chodzi.

O dzięki, to rozwiązanie znacznie bardziej mi sie podoba - nieco przejrzystrze jest. Z tego co rozumiem do db bede musiał powpisywac wszystkie mozliwości,czyli:

600|600|xyz
700|600|zzz
800|600|xxx
...
600|700|yyy
700|700|xyz
800|700|zxy
etc.

Dokładnie. Najlepiej wszystkie możliwości (choć brak wpisów nie będzie skutkował tragedią, a poszerzeniem przedziału, jednak nic nie stoi na przeszkodzie, by wysokość i szerokość były od siebie niezależne, tzn. miały inne przedziały.