![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 55 Pomógł: 0 Dołączył: 31.12.2006 Ostrzeżenie: (0%) ![]() ![]() |
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: Kod wys\szer 500-600 601-700 701-800 801-900 itd. 500-600 150 326 489 zzz 601-700 389 489 550 zzz 701-800 xyx yxy yyx xxy 801-900 xxx yyy yxx xyy itd. 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 ![]() |
|
|
![]() |
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 706 Pomógł: 108 Dołączył: 12.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
Masz już zrobioną tabelę w MySQL z cennikiem? Jeśli tak to pokaż strukturę.
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 55 Pomógł: 0 Dołączył: 31.12.2006 Ostrzeżenie: (0%) ![]() ![]() |
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...
|
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 706 Pomógł: 108 Dołączył: 12.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
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
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ą. Ten post edytował croc 13.05.2010, 09:05:26 |
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 55 Pomógł: 0 Dołączył: 31.12.2006 Ostrzeżenie: (0%) ![]() ![]() |
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? |
|
|
![]()
Post
#6
|
|
![]() Grupa: Zarejestrowani Postów: 706 Pomógł: 108 Dołączył: 12.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
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:
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. Ten post edytował croc 13.05.2010, 15:03:41 |
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 55 Pomógł: 0 Dołączył: 31.12.2006 Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]()
Post
#8
|
|
![]() Grupa: Zarejestrowani Postów: 706 Pomógł: 108 Dołączył: 12.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
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.
|
|
|
![]() ![]() |
![]() |
Aktualny czas: 22.08.2025 - 00:53 |