Partitionarea aduce imbunatatiri reale cind este corect facuta.

Pentru ca sa fie efectiva trebuie ca planurile de access sa poata beneficia de informatia ca numai o partitie contine datele de interes si sa nu acceseze celelate partitii (adica o clauza WHERE care sa fie SARG-able si care sa contina conditii pe cimpurile din functia de partionare iar conditiile sa determine clar o singura partitie). Daca query-urile tale genereaza azi planuri cu full scan partitionarea nu o sa ajute cu nimic, ba chiar o sa mearge semnificativ mai incet din cauza complicarii compilarii.
View-urile sint structuri logice si partitionarea este structura fizica, intrebarea despre 'partitionarea' view-urilor' nu o inteleg. O intrebare mai sensibila ar fi daca partitionezi si indexsii, si anume care indexsi si cum.
Timpul de insert in general ramine neschimbat (se adauga la planul de insert determinarea partitiei si cam atit). Ca idee generala este foarte rar cazul cind timpul de insert este relevant (ai un OTLP cu peste 1000 de tranzactii pe secunda? sincer ma indoiesc). Daca aplicatia ta are timpi mari de insert este mult mai probabil ca problema este din design-ul aplicatiei si timpul este pierdut in asteptare de lock, nu din accesul fizic. Partitionarea nu o sa rezolve asa ceva.

Idee este ca partitionarea este un subiect destul de avansat. Nu te apuca de ea pina nu intelegi exact ce face si cu ce te-ar ajuta. Probabil in applicatia ta si baza ta de date sint inca 100 de imbunatatiri de facut care sint mai simple decit partitionarea si vor aduce rezultate imediate. In primul rind ar trebuii sa potzi sa enunti foarte clar care sint problemele actuale ale bazei de date si ale aplicatiei ('baza de date cu 3 ani fiscali' este o enuntare de clasa I, nu de administrator de system).  Si evident, cum ai masurat aceste probleme. Apoi poti sa enunti care sint avantajele partitionarii care ar rezolva unele din aceste probleme. Apoi putem discuta concret cu ce te ajuta sau nu te ajuta partitionarea.

---

http://rusanu.com