Który sposób na reset zmiennych wybrać ?

Użytkownicy mogą dziennie tworzyć 5 rzeczy. Mogę zapisać w tabeli users pole typu day_limit i tam aktualizowac ze np dziś zrobił 3 i system sprawdza ile może jeszcze wykonać.

Drugi sposób to zrobić tabelke oddzielną z user_id i day_limit i zamiast aktualizowac tabele users to zrobilbym truncate na te tabele.

Teraz taka rozkmina. Mam 3 mln uzytkowników. co dzien o 12 w nocy musze zrobic update i wyzerowac day_limit dla wszystkich ktorzy mieli wiecej niz 1 ewentaulnie dla wszystkich.

To szybsze bedzie truncate table ? i czy truncate jest dobrym pomyslem ? czy zamiast tego truncate zrobic reset na tej dodatkowe tabeli tylko. bo powiiedzmy jest 3 mln userow ale tylko 100 tysiecy cos robi wiec z pewnoscia bedzie mniej jesli zrobie oddzielna tabele

chomikowski napisał(a):

/ciach/
Nie podoba mi się to podejście, bo nie ma żadnej historii a bazę traktujesz jako tymczasowy magazyn danych.
No nie od tego są bazy danych, i IMO lepiej te dane utrzymać całkowicie poza bazą danych - nawet w pliku/plikach.

To szybsze bedzie truncate table ? i czy truncate jest dobrym pomyslem ?

W twoim przypadku będzie zarówno szybsze jak i lepsze.
trucnate table jest jazdą po bandzie, ale do tego jak to traktujesz się nada.

czy zamiast tego truncate zrobic reset na tej dodatkowe tabeli tylko.

Co to jest reset?
delete from tabela to nie jest reset.
Ale już drop i create table byłby ;-)
Tylko zdajesz sobie sprawę, że truncate table zadziała prawie jak drop i create i niesie ze sobą konsekwencje (proponuję manual doczytać co dokładnie się zadzieje)?

bo powiiedzmy jest 3 mln userow ale tylko 100 tysiecy cos robi wiec z pewnoscia bedzie mniej jesli zrobie oddzielna tabele

Oddzielna tabela daje inne możliwości, ja bym zrobił to poza główną bazą danych.

Jak masz userow dużo to lepsza będzie osobna tabela. I nie słuchaj tego chłopa powyżej zeby to w jakiś plikach trzymać. Informacja o limicie jest taka sama daną jak każda inna.

@CoJaTuRobie:

CoJaTuRobie napisał(a):

Jak masz userow dużo to lepsza będzie osobna tabela.

Ciekawe dlaczego...
Założę się, że rozwiązani oparte o plik byłby szybszy co najmniej o rząd wielkości.
Ale rozumiem, też kiedyś tak miałem, do momentu aż nie zacząłem organoleptycznie testować wydajności (dużo, ale bardzo proste dane) pliku vs baza danych.
Do takich zastosowań baza danych jest wygodna, ale nie jest to najszybsze rozwiązanie.

I nie słuchaj tego chłopa powyżej zeby to w jakiś plikach trzymać.

Chłopa to sobie w rodzinie poszukaj.

Informacja o limicie jest taka sama daną jak każda inna.

Każda informacja jest informacją - nie odkryłeś niczego nowego.
Ale jest też kwestia skali i dostępności rozwiązania, o czym albo zapominasz albo nie rozumiesz o czym mowa.

" pliku vs baza danych." - pilki i baza danych to jedno i to samo. przeciez baza danych to tez plik(i) xDDDD

Dokladnie, wszystko to jest plik i nie ma tu zadnej roznicy. Nawet katalog to tez plik. — chomikowski 36 minut temu

@chomikowski: nie wiem czy trollujesz, czy Ty tak serio. Ale jeśli nie widzisz różnicy między zapisem do pliku a korzystaniem z silnika bazy danych, który wprawdzie zapisuje ostatecznie dane na dysk w postaci plików, ale w międzyczasie robi i oferuje jeszcze 150 innych rzeczy, to może jednak zmień branżę. Kwiaciarze całkiem nieźle zarabiają.

Chociaż jak powiesz w kwiaciarni klientowi, że wszystko to jest roślina i nie ma tu żadnej różnicy i np. zrobisz wiązankę pogrzebową z kaktusów i paproci, to trochę słabo może wyjść :(

chomikowski napisał(a):

" pliku vs baza danych." - pilki i baza danych to jedno i to samo. przeciez baza danych to tez plik(i) xDDDD

Nie. To nie jest to samo. Baza danych może być reprezentowana np. jako plik ale plikiem nie jest.

Nie widzę żadnej zalety w użyciu plików tutaj, mamy 3 mln użytkowników. Zarówno jeśli będziemy tworzyć plik per user, jak i jeden plik, to jak pomyślę o wyszukiwaniu (indeksy), uaktualnianiu (zrównoleglenie) i obciążeniu dla dysku(często zmieniające się danych), to już nawet by nie było strzelanie w stopy tylko w kolana.

Baza danych się jak najbardziej nada, jak najbardziej oddzielna tabela, jak będą problemy z wydajnością, to takie liczniki są wręcz przykładowym zastosowaniem dla NoSql.
Co do tego jak to robić, to zależy jak masz rozłożony ruch w aplikacji, jak o północy nie masz ruchu, to TRUNCATE się nada. Jak masz ruch, to jednak bym poszedł w UPDATE.

Zrób sobie tabelę:

• data
• user_id
• day_limit

Dzięki temu oddzielasz czyszczenie od aktualizacji (mogą być niezależne).
I czyszczenie możesz robić paczkami z limitem - https://www.techonthenet.com/mysql/delete_limit.php
np. co 5 minut po 10 tys. gdzie data < aktualnej - https://stackoverflow.com/a/64052459
Dodatkowo wpis per user_id nie musi istnieć, jeśli go nie ma to zakładasz że nie było aktywności użytkownika i przyjmujesz wartość domyślną.

Natomiast jeśli masz Redisa, to on ma taką funkcjonalność wbudowaną - patrz https://redis.io/commands/expireat