Często podczas kodowania czegokolwiek opartego o bazę danych, np sklepu myślałem sobie jak obsłużyć odpowiednio "stare" dane.
Pójdę przykładem sklepu. Powiedzmy, że jes tabela zamówienia:
[sql:1:f6e7216490]
CREATE TABLE zamowienia(
id INT UNISGNED NOT NULL AUTO_INCREMENT,
opis CHAR(20) NOT NULL,
PRIMARY KEY(id)
);
[/sql:1:f6e7216490]
Sklep działa już od 3 lat i tabela tak sie rozrosła, że pobieranie zamówień z bierzącego miesiąca (najczęściej wykonywane zapytanie na tej tabeli) trwa dość długo.
Zawsze myślałem o tym, w jaki sposób przenosić "niepotrzebne" w danym okresie dane w takie miejsce, żeby jednak można było z nich skorzystać w dowolnej chwili a żeby nie powodowały spowolnienia tych najczętszych zapytań.
Chyba rozumiecie o co mi chodzi
(mam nadzieję)
Tego typu rozmyślenia czy plany zawsze miałem w głowie, nigdy nie zaimplementowałem żadnego rozwiązania tego "problemu".
No i stało się, że czytam sobie książeczkę o MySQL'u i natrafiłem na pojęcie tworzenia tabel typu MERGE i stwierdziłem, że to właśnie idealny sposób rozwiązania "problemu" o, którym piszę.
Domyślam się, że twórcy MySQL'a stworzyli ten typ tabeli m.in. do takich zastosowań ale ciekawy jestem czy wy z tego korzystacie i jeśli tak to w jakich sytuacjach i jak to się sprawdza w praktyce. Czytałem, też że czasami tabele tego typu mogą się okazać kłopotliwe.
Może znajdzie się ktoś znający temat z doświadczenia, byłoby miło
edit...
Przypomniałem sobie o jeszcze jednym nurtującym mnie pytaniu.
O ile można mieć w mySQL transakcje używając tabel typu InnoDB o tyle przy zastosowaniu tabel typu MERGE są to tak naprawdę tabele typu MyISAM - co w tedy z transakcjami? Macie jakiś sposób na osiągnięcię tego co dają tabele MERGE'owane i jednocześnie zachowanie możliwości wykonywania transakcji
Ja sobie radzę siekając dane rocznikami (table --> n * table_rrrr) , ale zawsze pozostaje problem, co zrobić z zamówieniem z grudnia realizowanymi w styczniu