Jak zapisywac narzut procentowy dla różnych kategorii Opcje

[jajcarzd1]

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

Kod

idCategory,idParent,name, ....

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

Ten post edytował jajcarzd1 26.07.2010, 13:58:34

[Pilsener]

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.

np. dla jakiejś kategorii najwyższego poziomu próg rabatowy 5%, więc musze zapisać również wszystkie kategorie podrzędne z taką wartością

- 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?

[jajcarzd1]

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

Robisz tabelę:
user | kategoria | rabat

I dołączasz left joinem do danej kategorii.

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

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.

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%.

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?

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

[Pilsener]

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

- 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.

[jajcarzd1]

- 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.

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.

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.

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


Chyba jednak spróbuję zrobić tabelę

Kod

user | kategoria| narzut

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.