Dzięki za odpowiedzi.
a ja bym powiedział, że najpierw to się należy zastanowić nad tym, czy w ogóle partycjonowanie jest potrzebne
Bo jeśli struktura i zapytania są do d**y to ani serwer za grube miliony ani partycjonowanie nie pomoże. Jak coś działa wolno to najpierw należy się przyjrzeć konfiguracji samej bazy (ale oczywiście o tym, aby napisać co to za SZBD to już genialny umysł nie wpadł) a następnie planom wykonania samych zapytań. BTW ta spora baza to ile ma 10GB, 100GB, więcej czy 100MB i "już" działa wolno.
Baza oracle, około 30GB. Wcale nie działa wolno ale możliwy jest w najbliższym czasie znaczny wzrost liczby operacji. Struktura i zapytania są ok, partycjonowanie rozważane jest jako jedna z metod optymalizacji bazy. Jak da się zaoszczędzić trochę zasobów...
Inna sprawa, że partycjonowanie ma zazwyczaj sens w przypadku danych archiwalnych. Za takie dane można uznać np. poprzednie lata z danymi dotyczącymi sprzedaży. Wtedy zasadne jest partycjonować te dane wg roku, w którym była sprzedaż. Przy dużej ilość danych nawet po miesiącu sprzedaży.
Dla przytoczonego przez Ciebie przypadku to działa w ten sposób że co miesiąc (lub co rok) tworzę nową partycję z kolejnym miesiącem (rokiem) danych?
A moze index z warunkiem? np
INDEX1 ... WHERE KlientId = 1;
INDEX2 ... WHERE KlientId = 2;
etc
Czyli przyjmując że już zrobiłem te partycje ze względu na rodzaj poduktu. Jak miałby wyglądać ten index? Jeden produkt może mieć wiele klientów. Z Twojego przykładu rozumiem ze każdy klient będzie miał swój index? To chyba nie jest możliwe.