Witam

Mam takie pytanie. Otóż posiadam w bazie kilka tysięcy produktów, produkty te należą do róznych kategorii i jest ich na chwilę obecną (tych kategorii) około 1400. Dany produkt nalezy do jednej kategorii. Kategorie są przechowywane w tabeli według schematu



Teraz administrator systemu może każdemu użytkowikowi tego systemu przypisac różny narzut procentowy dla każdej z kategorii. Produkty są przechowywane w z cenami netto zakupu. I teraz pytanie w jaki sposób przechowywać te wartości
aby potem móc swobodnie obliczać wartości cen produktów gdy dany użytkownik je sobie przegląda. Jest to coś w stylu B2B. Zakładając że administrator określi np. dla jakiejś kategorii najwyższego poziomu narzut 5%, więc musze zapisać również wszystkie kategorie podrzędne z taką wartością. Potem jednak jeśli chce pobrać z bazy np 1000 produktów naraz to muszą w jakiś sposób sprawdzić dla danego produktu jaki jest dla niego narzut a własciwie dla kategorii do której należy a następnie go obliczyć.

Jakie macie pomysły na coś takeigo

Będę wdzięczny za wszelkei info.
Pozdrawiam

Robisz tabelę:
user | kategoria | rabat

I dołączasz left joinem do danej kategorii.

Teraz kwestia, czy implementować dziedziczenie rabatu czy nie. Jeśli tak, to dojdzie kolejne pole: dziedziczenie (0 lub 1). Jak to działa? Przykładowo user patrzy na ceny w kategorii filmy/filmy-sensacyjne/filmy-do-50-zabitych, jeśli dla tej kategorii nie ma ustawionego rabatu to aplikacja szuka rabatu z włączonym dziedziczeniem wyżej aż do kategorii głównej.

Dziedziczenie cech w drzewie jest trudne w implementacji (tutaj moim zdaniem przydają się drzewka metodą IP, ale niech każdy robi jak ludi/umie) i rzadko się je spotyka. Najczęściej trzeba ustawić jakąś właściwość dla wszystkich kategorii i podkategorii - od tego radzę zacząć, bo jest to proste do wykonania.

- to nie jest takie proste, bo weźmy np. te filmy: chcę ustawić rabat 5% dla całej kategorii ale np. w filmach do 50 zabitych robię wyprzedaż i chcę dać 20% - i co wtedy?

Na początku poprawka nie miałem na myśli progu rabatowego tylko wartość narzutu procentowego, gdyż produkty mam zapisane z cenami netto zakupu. Sorki za ten błąd. Już poprawiam w poście



No tu akurat problemu może nie ma bo w taki sposób też myślałem aby zapisywać wartości narzutów, ale problemem jest potem w locie określenie ceny dla danego usera robiąc selecta dla produktów. Bo w danym selecie muszę pobrać produkty dla każdego pobrac wartośc narzutu z ewentualnej tabeli narzutów, jesli takiego nie ma to przypisują domyślny i wtedy wyliczam cenę netto sprzedaży dla danego kontrahenta. I nie mam na to pomysłu za brdzo żeby było to wydajne



Generalnie to jeśli nie ma określonego narzutu dla danej kategorii to przypisuję wartość domyślną jak jest zdefiniowana ogólnie dla danego usera np 10%.




Będzie liczony narzut dla danej kategorii nie będzie sumowania itp. Tak jak pisałem wyżej, jesli kategoria nie ma przypisanej wartości to narzut domyślny

- ciężko teoretyzować, generalnie dołączanie małych tabel przy relacji jeden do jednego śmiga jak burza (jak masz indeksy), operacje matematyczne też należą do jednych z szybszych. Problem może być wtedy, jeśli masz dużo userów i dużo produktów, wtedy można:
- dodać dodatkowe pola, przeliczane przy modyfikacji danych danej tabeli/tabel
- rozbijać tabele na mniejsze (np. każda główna kategoria produktów w innej tabeli)

Najlepiej sprawdzić testując obciążenie, nie ma sensu martwić się na zapas.

Hmm ale nie bardzo wiem co masz a myśli, co by się miało znaleźć w tych tabelach, bo na chwilę obecną tak jak wspomniałem wcześniej jest już pracująca struktura tabeli produktów i kategorii.



Userów wielu nie będzie ale produktów aktywnych oscyluje w okolicach od kilku do kilkunastu tys.


Chyba jednak spróbuję zrobić tabelę



tylko że w trakcie definiowania tych wartości będę zapisywał od razu do tej tabeli wszystkie potomne kategorie jeśli dana kategoria takowe posiada i wtedy dość łatwo powinienem pociągnąć left joinem wartość narzutu bo każdy produkt ma pole kategorii w tabeli produktów.