sum(wiele rekordów)

0

Otóż tworzę mały skrypt finansowy na bazie MySQL i są tam różne operacje w postaci:

[ ID_OPERACJI | DATA_OPERACJI | OPIS_OPERACJI | KWOTA_OPERACJI | SALDO_PO_OPERACJI ]

i w jaki sposób ma wyliczać aktualne saldo? Sumować wszystkie rekordy z kolumny KWOTA_OPERACJI? Czy to nie będzie mieć znacznego obciążenia, bo rekordów będzie dość dużo - parenaście tysięcy lub nawet kilkadziesiąt.
Może jest jakaś inna metoda? Wolałbym uniknąć innej tabeli z saldami, bo to odwoływanie się do 2 tabel, a więc jeszcze większe obciążenie. Chcę po prostu uzyskać najlepsze rozwiązanie.

Pzdr.

0

Po pierwsze klikadziesiąg, czy kilkaset tysięcy rekordów w takiej strukturze (mała tabela) to dla bazy danych raczej nie jest duże wyzwanie. U mnie kierownik na tabele < 10 mln rekordów, mówi że są małe :P

Jeśli założysz index na kolumne na której będziesz wykonywał operacje to wszystko powinno być ok.

Nie wiem dokładnie jak wpisujesz dane do bazy, ale dla mnie saldo_po_operacji ostatniego wpisu to jest saldo aktualne....

0

Kolego sympatyczny. Bazy danych właśnie do tego służą! One są stworzone w taki sposób aby móc łączyć w zapytaniach tabele i agregować dane. Operacja JOIN na tabelach czy SUM to całkowicie normalne i naturalne operacje, z którymi baza danych świetnie sobie radzi, nawet jeżeli chcesz sumować tysiące, a nawet miliony rekordów. Naprawdę nie rozumiem dlaczego domorośli programiści, kodujący wszelkiej maści skrypty w PHP tak się boją baz danych, a szczególnie boją się JOIN-ów?!

Po drugie zastanów się czy na pewno potrzebujesz w każdej linijce operacji mieć informację o aktualnym saldzie? Po trzecie zastanów się czy tego pola nie da się wyliczyć inaczej niż sumując wszystkie rekordy, może wystarczy do salda z poprzedniego rekordu, dodać kwotę operacji z nowego? Ja dokładnie nie odpowiem na pytanie jak to zrobić, ponieważ nie wiem co tak naprawdę chcesz zrobić i po co?

0

Tak, saldo_po_operacji ost. wpisu to jest jakby saldo aktualne. Jest to bardzo podobne to wyciągu z konta bankowego.
Czyli wiele zapytań typu sum(*) dla kilkuset tysięcy rekordów nie powinny mieć większego wpływu na wydajność?

1

wydajność bazy danych zwykle nie zależy od ilości danych, które zawiera, tylko od ilości danych, które musi przetworzyć, żeby zwrócić wynik i od rozmiaru samego wyniku. dobrze zaprojektowana baza zawiera odpowiednie indeksy i może być partycjonowana, żeby odwoływać się do jak najmniejszej ilości rekordów w tabeli (index seek). z Twoich pytań wynika, że nie wiesz co to plan wykonania i nie wiesz co to indeks i jak działa - polecam zapoznać się z tematem.

upraszczając:

  • zapytanie, które z milionów rekordów ma zwrócić sumę kilkuset, na odpowiednio zaprojektowanej tabelce wykona się bardzo szybko i nie zużywając dużo zasobów (pamięć i I/O).
  • zapytanie, które z milionów rekordów ma zwrócić sumę kilkuset tysięcy, na odpowiednio zaprojektowanej tabelce wykona się względnie szybko, choć zużyje dużo zasobów.
  • zapytanie, które z milionów rekordów ma zwrócić kilkaset tysięcy rekordów, na każdej tabelce wykona się powoli i zużyje bardzo dużo zasobów.
0

krotko i na temat.

Jesli potrzebujesz sald (narastajaco po wierszu itp) to nie polecam wyliczac tego w zapytaniu.
Robisz tak:
a) zrzucasz dane do tabeli (moze byc tymczasowa) najlepiej przez into z uzycien 0.00 [Narastajaco]
b) dopiero teraz robisz update kolumny narastajaco

Robiac update kolumny narastajaco masz kilka rozwiazan.

Ja pracuje na MSSQL i tam sprawdzaja sie 2 rozwiazania:
a) najlatwiejsze (pamietaj ze dane musza byc wstawione w kolejnosci agregowania) UPDATE ##TABLE = SET @zmienna = narastajaco = @zmienna + kolumna_sumowana
b) CLR (troche trudniejsze) - warto o tym poczytac

1 użytkowników online, w tym zalogowanych: 0, gości: 1