Historia bazy danych - codzienna archiwizacja.

Witam,

Mam taki nietypowy problem. Otoz w programie, ktorym sie aktualnie zajmuje powstala potrzeba tworzenia historii towarow umieszczonych w pewnej ilosci komor w firmie. Archiwizacja danych MUSI odbywac sie codziennie. Teraz w bazie znajduje sie jedna tabela, ktora zawiera dane w kazdej z komor np:
idKomory idTowaru dzienWlozeniaTowaru itd.

Najprostszym rozwiazaniem bylo by kopiowanie istniejacej tabeli do innej o nazwie dnia np: 22-11-2011, a pozniej odnoszenie sie do niej. Jednak przy dluzszej archiwizacji ilosc tabelek w bazie bedzie sie nieskonczenie zwiekszac.

Drugim pomyslem byloby stworzenie ilosci tabel odpowiadajacej ilosci komor i tylko dodawanie nowych rekordow, a pierwszy rekord okreslalby aktualny stan bazy. Tylko teraz czy joinowanie by dzialalo dosyc szybko dla ilosci>100?

A moze ja zle mysle, i mozna to inaczej/latwiej rozwiazac?

ps1. Przepraszam za brak polskich znakow :)

trzymać wszystko w jednej tabeli. Nie potrafię zrozumieć po co chcesz to rozbijać na n tabel. Jeśli tych danych będzie bardzo dużo to osobno tabela "produkcyjna" i osobno archiwalna a jak nie to nawet nie rozbijać na dwie tabele tylko dodać pole archiwalne i tyle

Nie wiem, taki pomysl mialem.

Czyli wtedy tablica z aktualnymi by miala wyglad np.
idKomory idTowaru dzienWlozeniaTowaru itd.

A archiwalna:
idKomory idTowaru dzienArchiwizacji dzienWlozeniaTowaru itd

Cos takiego?

a potrzebna Ci jest ta data archiwizacji?? Potrzebna Ci jest w ogóle osobna tabela? Ile rocznie będzie tam danych przybywać?

Po pierwsze jak długo chcesz trzymać dane archiwalne i ile ich jest (setki, tysiące, miliony rekordów). Jeżeli przez krotki czas to można trzymać w tej samej tabeli. Jeżeli dłużej to warto przepisywać je do osobnej tabeli tak by uniknąć sytuacji w której po 10 dniach ilość przydatnych (bieżących) danych to tylko 10%. Po 100 dniach masz tylko 1% danych bieżących, a reszta to archiwum.
Po drugie jaki silnik bazy danych. Niektórzy dostawcy oferują narzędzia pozwalające na proste tworzenie archiwum.

Generalnie drogi są trzy.

1. Ta sama tabela powiększona o kolumnę czy_archiwum. Dobre rozwiązanie przy małych ilościach danych i krótkim czasie przechowywania danych archiwalnych.
2. Osobna tabela. Dobre rozwiązanie jeżeli chcesz przechowywać dużo danych przez dłuższy okres. Dodatkowo można tu utworzyć m.n. widoki materializowane (oracle), które będą wspomagać niektóre zapytania. Wymaga to jednak dużo miejsca na bazę. Zaletą jest w miarę szybki dostęp do wszystkich danych historycznych.
3. Osobna tabela + plik archiwalny, czyli sytuacja w której chcesz mieć dostęp do wszystkich danych archiwalnych, ale najstarsze z nich nie muszą być dostępne od ręki. W takim przypadku dane w tabeli archiwalnej lezą przez pewien czas, a następnie najstarsze wpisy są zrzucane do pliku i usuwane. Dobre rozwiązanie jeżeli z jednej strony chcesz mieć dostęp do bardzo starych danych, ale z drugiej nie masz wystarczająco dużych zasobów by utrzymywać pełne archiwum w pełnej gotowości.
   Odczyt danych z archiwum plikowego przebiega w dwóch etapach:

• ładujesz pliki, które chcesz przeszukać do tabeli tymczasowej.
• zapuszczasz zapytanie na czymś w stylu :

select * from (Select * from archiwum union Select * from arch_temp_14312) archiwum where ... 

gdzie arch_temp_14312 to nazwa tabeli tymczasowej.

Względnie stawiasz klaster i nie masz problemu (tego, bo pojawiają się nowe).

Rocznie przybędzie ilośćKomór * ilośćDni rekordów. Najlepiej jakby dane się dało trzymać przez rok, dwa. Umożliwiło by to robienie szczegółowych zestawień zawartości komór na przestrzeni dni, potrzebnych klientowi.
Aktualnie jest MySQL, ale najprawdopodobniej będzie zmieniane do MS SQL.

nawet jakby tych komór było 1000 to w rok masz niecałe 500tyś rekordów - przecież to jest "pan pikuś" dla bazy. Tu się nawet nie ma co zastanawiać nad osobnymi tabelkami tylko dać to do jednej + info czy archiwalny czy nie i indeks i po problemie