[GreeenOne]

#programowanie #it #backendd #bazadanych #php #laravel Wracam z kolejnym pytaniem a propo danych i backendu :)"

Na jednej ze stron mam listę opłat odnośnie danego zadania oraz statystyki na zasadzie ile opłat, jaka jest ogółna kwota opłat, ile nie jest opłaconych itp. Zastanawiam się jak podejśc do statystyk

- Stworzenie tabelki ze statystykami która by przechowywała statystyki a w momencie zmianych opłat, statystyki by były aktualizowane.
- Wyliczanie na bieżąco danych

Wydaje mi się, że drugie rozwiązanie jest lepsze. Nie przewiduję aby było więcej niż 1000 opłat na dane zadanie (To jest taki skrajny maks) a użytkownik pewnie będzie wchodzić z kilka razy na stronę dziennie. No i przede wszystkim dane się nie rozjadą.

Jak to wygląda tez w kwestii performance? Wydaje mi się, ze powinno dać radę ale gdyby by było dużo osób korzystających z platformy, to może jednak coś zlagować?

[mccloud]

@GreeenOne: materialized view, ktory po insercie sie przeliczy a strona tylko wyswietla z niego dane?

[Radaka]

@GreeenOne: zawsze w sumie jest lepiej trzymać gotowe wyliczenia w bazie danych, później zawsze mogą dojść jakieś raporty czy inne rzeczy i za każdym razem będzie trzeba mielić bazę.

Jak na szybko to całość możesz trzymać w cache i tylko odświeżać po zmianie

[ShiroUmizake]

@GreeenOne: Po pierwsze ile tych opłat/transakcji by było dziennie? Ja bym to zrobił event kolejce i inny sytem niech bawi się liczenie tych statystyk, jakis konsumer/producer i wsio (i masz skalowalnosc przy okazji, jak dojdzie ci wiecej eventow po prostu dokladasz konsumera czy producera)

Co do twojego pytania czy twoje rozwiazanie mogloby zlagowac.

Tak, jesli nie masz cachu danych , przy 1 000 000 rekordow troche by to liczylo a

[markaron]

@GreeenOne: Dokładnie jak napisałeś. Przy małej skali jakiś widok czy procedura na bazie danych która będzie robiła obliczenia na żądanie wystarczy. Przy dużej skali takie operacje robi się w tle i zapisuje gotowy wynik do bazy danych.

Zacznij od wyliczania na żądanie za pomocą widoku albo procedury w SQL, ja nie liczyłbym tego w aplikacji.

Pójście od początku w kolejki, przetwarzanie asynchroniczne po stronie serwera, itd gdy jeszcze nie znamy