Zmiana zliczania punktów, algorytm

Mam taką sytuacje, że zliczam w moim projekcie punkty za zamówienia. Mam już jakąś historie punktów, user ma nazbierane punkty załóżmy przez około rok czasu. Ale teraz chce wprowadzić datę od której będą punkty zliczane czyli np. 3 miesiące. W bazie mam to tak ograne, że mam tabelke z zarobionymi i wydanymi punktami np. +50 dla usera, -40 itp - to jest po prostu sumowane. Problem jest taki że jeśli wprowadze datę graniczną w trakcie, to user może mieć błędnie liczone saldo lub saldo może wyjść na minus. Przykładowo jeśli datę graniczną wprowadzę 01.10.2024, a klient zdobył punkty we wrześniu, ale wydał je w listopadzie
Macie pomysł na rozwiązanie takiego problemu?

Nie wiem czy miałbym to ograć na poziomie bazy (mysql) czy już w samym kodzie (java)

1 stycznia dostałeś 50 pkt, 1 lutego zużyłeś 30 pkt, to 1 kwietnia chcesz mieć 30 pkt czy 0?

Piszesz o algorytmie, a opisujesz to słownie, algorytmy się pisze operacjami matematycznmi jakie przeprowadzasz ruch za ruchem.
Tak wygląda algorytm https://www.researchgate.net/profile/Felipe-A-Moreno-2/publication/340060033/figure/fig1/AS:1020202913382401@1620246737898/Deep-Mind-DQN-algorithm-with-experience-replay-5.ppm

A to co ty podałeś to, opis problemu, który nie jest w 100% jasny.
Dostanę w styczniu 50 pkt, w lutym wydam 20pkt, w marcu dostanę 10pkt, w kwietniu 15 pkt, to ile będę miał w maju?
Powinno być 25, bo tamte ze stycznia nawet jak wydane to już przepadły.
Bardzo dobrze musisz sformalizować opis problemu, problem to nie jest czy w javie czy mysql, tylko jak to zrobić, żeby spełniało wymagania, a przepisanie z jednej technologii na drugie to ci bot wygeneruje LLM.

Czyli w tym przykładzie to by było, że ignorujesz do pierwszego dodanego punktu od tych 3 miesięcy w wstecz i obliczasz wszystko.
Możesz to kompresować czyli jak raz przeliczysz to ściskać te wszystkie wartości, ale wtedy mogą się stare wartości kumulować, czyli w sumie źle mówię teraz, bo to nie zadziała.

Patrzysz wstecz do pierwszego dodatniego wpływu punktów od trzech miesięcy do przodu, ignorując ujemne i od dodatniego startujesz i od tego miejsca dodajesz wszystko normalnie do aktualnej daty.

Stwórz sobie joba, który okresowo sprawdzi, czy punkty się przedawniły i jeśli tak, dopisze do tabeli operację przedawnienia z ujemną wartością. Podliczanie stanu konta zostaw jak jest

Można to optymalizować na wiele sposobów. Można też po każdej operacji aktualizować stan konta zapisany w kartotece właściciela ( wtedy nic nie trzeba liczyć, a historia jest tylko poglądowa)

Chodzi o to, że teraz punkty mam bezterminowe. Ale w trakcie "działania punktów" chce wprowadzić ograniczenie wazności punktów, czyli przykładowo punkty liczymy od 01.10.2024r.
Przykładowa dotychczasowa historia punktów usera:

Nowa data od której punkty powinny być liczone: 01.10.2024r.
Teraz pytanie, jaką ilośc punktów powinien mieć user? Bo w tym momencie jak zacznie liczyć od 01.10 to będę na minusie
Zastanawiam się nad dodaniem kolumny 'ważne do', ale nadal pozostaje z problemem

Nie wiem, co to za system i jaka jest zależność między wystawcą j korzystającym z punktów, ale zazwyczaj prawo nie działa wstecz. Zazwyczaj w programach lojalnościowych podczas wprowadzania przedawnienia daje się użytkownikom czas na wykorzystanie starych punktów. Ale chyba nie o tym tu będziemy opisać. Dla mnie oczywistym jest, że stan konta punktowego nie może spaść poniżej zera. Jeśli chcesz tu odstawiać kombinacje alpejskie, to stan na 02.10 wynosi 0, a na 02.11 nadal 0.

Nie chce odstawiać żadnych kombinacji alpejskich, po prostu pytam czy można zarządzić tym problemem

Skoro mamy datę graniczną to można przyjąć, że to co się działo wcześniej nas nie interesuje: punkty zdobyte wcześniej musiał wykorzystać (albo przepadły), a także nie mógł zacząć okresu z saldem ujemnym. Także wydaje mi się, że po prostu robisz tak:

SELECT SUM(ilosc) AS saldo FROM zamowienia WHERE data > '2023-01-01';

I tutaj masz sumę wszystkich uznań oraz obciążeń konta od wskazanego dnia do chwili obecnej.
Czy o to chodziło? Jeśli nie to napisz dokładniej w czym jest problem.

tutaj rozpisałem dokładnie sytuacje: #1995017
Jeśli ustawie date graniczną i zaczne od niej po prostu zliczać punkty, to mogę wejść na minus salda ponieważ powyżej tej daty granicznej będzie historia w której użytkownik korzystał z punktów sprzed daty granicznej

To może po prostu policz, ile punktów użytkownik zużył ponad saldo j dodaj je do historii w dacie granicznej.

marcin33 napisał(a):

tutaj rozpisałem dokładnie sytuacje: #1995017
Jeśli ustawie date graniczną i zaczne od niej po prostu zliczać punkty, to mogę wejść na minus salda ponieważ powyżej tej daty granicznej będzie historia w której użytkownik korzystał z punktów sprzed daty granicznej

Wydaje mi się, że problemem tutaj nie jest samo zapytanie SQL (albo zliczanie punktów w ramach logiki aplikacji) tylko założenia/regulamin programu premiowego.
Zobacz - jeśli mamy tak, że po jakimś czasie (np. 30 dniach) punkty tracą ważność, to nie ma możliwości, że cofamy się o 30 dni (lub inny, ustalony czas, po którym punkty powinny przepaść) i najpierw pojawiają się wartości ujemne (pobieranie punktów). Jeśli miał 30 dni na ich wykorzystanie i cofniemy się od dzisiaj o 30 dni, to wszystkie punkty wystawione przed tym okresem są już nieważne - także nie ma prawa pojawić się JAKO PIERWSZA operacja zmniejszająca liczbę punktów.

Moja propozycja - zastanów się dokładnie (tak na papierze, nie w kategorii języka programowania/algorytmu/konkretnej implementacji) jak to ma działać i wtedy wrócimy do tematu.

ChłopPrzyszłyRycerz napisał(a):

1 stycznia dostałeś 50 pkt, 1 lutego zużyłeś 30 pkt, to 1 kwietnia chcesz mieć 30 pkt czy 0?

Piszesz o algorytmie, a opisujesz to słownie, algorytmy się pisze operacjami matematycznmi jakie przeprowadzasz ruch za ruchem.
Tak wygląda algorytm https://www.researchgate.net/profile/Felipe-A-Moreno-2/publication/340060033/figure/fig1/AS:1020202913382401@1620246737898/Deep-Mind-DQN-algorithm-with-experience-replay-5.ppm
A przy okazji, jeśli szukasz trochę rozrywki poza algorytmami, osobiście lubię spędzać czas w https://mostbet-casino-official.com/ – fajna platforma na relaks i drobną adrenalinę przy zakładach online.
A to co ty podałeś to, opis problemu, który nie jest w 100% jasny.
Dostanę w styczniu 50 pkt, w lutym wydam 20pkt, w marcu dostanę 10pkt, w kwietniu 15 pkt, to ile będę miał w maju?
Powinno być 25, bo tamte ze stycznia nawet jak wydane to już przepadły.
Bardzo dobrze musisz sformalizować opis problemu, problem to nie jest czy w javie czy mysql, tylko jak to zrobić, żeby spełniało wymagania, a przepisanie z jednej technologii na drugie to ci bot wygeneruje LLM.

Czyli w tym przykładzie to by było, że ignorujesz do pierwszego dodanego punktu od tych 3 miesięcy w wstecz i obliczasz wszystko.
Możesz to kompresować czyli jak raz przeliczysz to ściskać te wszystkie wartości, ale wtedy mogą się stare wartości kumulować, czyli w sumie źle mówię teraz, bo to nie zadziała.

Patrzysz wstecz do pierwszego dodatniego wpływu punktów od trzech miesięcy do przodu, ignorując ujemne i od dodatniego startujesz i od tego miejsca dodajesz wszystko normalnie do aktualnej daty.

Dokładnie tak, trzeba najpierw jasno określić zasady przeliczania punktów w czasie. Kluczowe jest, żeby brać pod uwagę, które punkty już wygasły i które są aktywne w danym momencie. W Twoim przykładzie punkty ze stycznia, jeśli przepadły po trzech miesiącach, nie wchodzą w obliczenia na maj, więc nie sumują się z nowymi przyrostami.

Algorytm powinien działać następująco:

Idziesz chronologicznie od najstarszego przyrostu punktów, który jest nadal aktywny.

Ignorujesz wszystkie punkty ujemne przed pierwszym dodatnim punktem w danym okresie.

Sumujesz aktywne punkty miesiąc po miesiącu, uwzględniając wydania punktów tylko wtedy, gdy są dostępne.

Punkty, które przepadły (po upływie okresu ważności), są odrzucane i nie wpływają na sumę.

Dzięki temu otrzymujesz dokładną liczbę punktów na dany miesiąc bez kumulowania przeterminowanych wartości.