Witam
Mam zrobiony skrypt do dodawania zamówień. Mam w bazie około 100-150 produktów do zamówienia. Dziennie około 50 kientów złoży zamówienie czyli w tabeli 'ZAMOWIONE_PRODUKTY' będzie mi dochodziło około 500 rekordów dziennie. Mam pytanie odnośnie pracy tej tabeli z tak wieloma rekordami po roku czy będzie wydajna? Czy lepiej wrzucić te zamówione produkty do tablicy i przechowywać tablicę w bazie?
tablica to najgorszy pomysł.
jak rozmiar tabeli dojdzie do powiedzmy 200GB to wtedy zaczynaj się zastanawiać czy jest co optymalizować. Na razie nie martwiłbym się o ilość danych i trzymał je jako rekordy osobne.
super dziękuję za pomoc. Wpadłem jeszcze na pomysł że jezeli na koniec miesiąca z zamówienia zostanie wygenerowana faktura zamówienie może zostac usunięte z bazya przetrzymywac w jakiś sposób tylko faktury
radziłbym nie usuwać. Może Ci się to przydać kiedyś. Danych o zamówieniu się przeważnie nie usuwa.
Rozwiązań jest kilka:
- Możesz ustawić mechanizm partycjonowania w MYSQL (to jest "wyższa szkoła jazdy"). Efekt będzie taki że dane będą dalej w 1 logicznej strukturze tabeli ale pod spodem dane będą podzielone na kawałki. W zależności od wielkości partycji (np. partycje po 6mc) jak będziesz chciał przeszukać dane z ost. miesiąca to mysql udeży tylko do tego kawałka bazy. Daje to duży wzrost wydajności przy dużych bazach.
Inny wariant to utworzenie tabel archive do którzej będziesz sobie cyklicznie przenosił dane, w ten sposób masz główną tabelę szybką, a archiwum możesz sobie nawet wyeksportować na inny serwer.
Nic nie zyskasz usuwając zamówienia, jedynie stracisz historię i klienci też nie będą mieli wglądu do archiwum bo go nie będzie. Dane do generowanych faktur wyciągaj do osobnej tabeli żeby były niezależne od ewentualnych zmian na tabeli z produktami a historia zamówień niech sobie będzie. Te ilości danych o których piszesz to dla mysql-a żaden wysiłek
dziękuję wszystkim za podpowiedzi i pomoc
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)