Zmniejszenie rozmiaru bazy

Cześć, mam bazę danych stołówki, w której jest zapisywane dużo dat, min. data wykupienia posiłku, data opłaty, data wydania i data przewija się jeszcze kilkanaście razy. Baza się szybko rozrasta, teraz jest na tyle duża, że samemu nie mogę zrobić jej dumpa tylko prosić o pomoc, a przy wyciąganiu większej ilości danych zapycha się dysk i program się wykrzacza. Czy pomogłoby (i czy jest to sensowne, stosowane) stworzenie tabeli daty, gdzie by było id_daty i data, a wszędzie tam gdzie wykorzystywana jest data wstawiane by było jej id. Dzięki temu zamiast dziesięciobajtowej daty w wielu miejscach mielibyśmy tylko w jednym, a wszędzie indziej tylko jej klucz obcy.

poza tym jakie metody optymalizacji bazy byście polecili prócz nadania indexów?

Troszkę w ciemno zakładam, że baza nie jest najlepiej zaprojektowana, ale trudno to potwierdzić nie znając jej budowy.
Napisz też co to za baza (MSSQL, MySQL, ...)?

teraz jest na tyle duża, że samemu nie mogę zrobić jej dumpa tylko prosić o pomoc

Co znaczy "duża"?
Na czym polega ta pomoc?

Baza to postgres, ale to samo tyczy się mysqla. Zajmuje kilkaset mega phpPgdmin wywala się przy robieniu zrzutu.

Baza jest tak zaprojektowana, że w większości tabel jest pole np. data_dodania, data_edycji, data_usuniecia.

Wątpię, żeby takie czarowanie z datami coś pomogło. Kilkaset MB to jest malutka baza danych. Twoim problemem są narzędzia, których używasz, nie baza.

Jeżeli uważasz, że to daty stanowią główny problem, to możesz zapisywać je w typie DATE, który ma 4 bajty ( http://www.postgresql.org/docs/9.1/static/datatype-datetime.html ).

Pytanie brzmi czy potrzebne są te wszystkie rekordy aplikacji na już, czy wystarczą tylko te z ostatniego miesiąca (roku?). Jeżeli nie potrzebujesz wszystkich, to starsze dane możesz co miesiąc (rok?) archiwizować w bazie (przenosić z TABELA do TABELA_ARCH) wcześniej robiąc backup TABELA (który będzie miesięcznym (rocznym?) backupem przyrostowym. Wtedy nie musisz backupować ciągle coraz więcej...

1. jakiego typu jest pole z datą?
2. phppgadmin to zabawka a nie poważne narzędzie - ściągnij sobie np. EMS SQL Manager Lite for Postgres - robi dumpy zdalnie

abrakadaber napisał(a):

1. jakiego typu jest pole z datą?
2. phppgadmin to zabawka a nie poważne narzędzie - ściągnij sobie np. EMS SQL Manager Lite for Postgres - robi dumpy zdalnie

timestamp without time zone

Próbowałeś robić Vacuum?

Krolik napisał(a):

Próbowałeś robić Vacuum?

Szczerze powiem, że nie wiem, o co chodzi z tym Vacuum, nigdy nie korzystałem. Wyczytałem tylko, że oczyszcza bazę z niezakończonych transakcji, albo poleceń drop table - tych poleceń praktycznie nie używam także nie wiem, czy jest sens używać vacuum.

Jeśli postgres działa podobnie do MSSQL, to większość rozmiaru bazy stanowią różnego rodzaju logi i być może do ich usunięcia służy Vacuum.
Kilkaset MB to nie jest dużo. Po co Ci dump? Backup z tego co przeczytałem robi się inaczej, a select'a wszystkich wierszy z tabeli nie robi się nigdy (chyba że to krótka tabela słownikowa), jeśli już zachodzi potrzeba przeglądania zawartości całej tabeli, to robi się to stronicowaniem.
Skąd pomysł, że data zajmuje 10 bajtów? Timestampy zajmują po 8 bajtów, a jeśli używasz date (która nie zawiera godzin/minut itp), to tylko 4.

Same indeksy to nie wszystko. Muszą jeszcze być używane i to efektywnie. Więc liczy się właściwy dobór typów pól do rodzaju danych (np. trzymanie daty w date, a nie w stringu, czy klucza głównego w int, a nie - ponownie - stringu itd), właściwa kolejność kolumn w indeksie (i w ogóle właściwe kolumny w indeksie, zarówno te, po których jest posortowany, jak i te dołączone do indeksu), rodzaj indeksu, analiza planów zapytań (czy jak to się nazywa w postgresie - żeby wiedzieć czy zaprojektowane zapytanie wykonuje się małym kosztem zasobów), odpowiednia architektura i normalizacja bazy danych (odpowiednia oznacza tylko świadome odstępstwa od 3PN), ... Temat rzeka.