Daca e vorba de BACKUP atunci intr-adevar nu ai prea mult cum sa-i reduci durata. Singura mea ingrijorare este ca faci backup din aplicatie. In general planul de backup trebuie lasat pe grija administratorului, separind responsabilitatzile de development (tu) fatza de cele de deployment (dba). Dar fara sa stiu detalii despre cum si unde se va folosi aplicatzia nu am cum sa judec, ce faci tu poate foarte bine sa fie corect (de ex. cind distribui o aplicatie care ruleaza pe 'auopilot', fara nici un fel de mentenantza, intr-un mediu unde nu exista dba). O sugestie ar fi sa te cosideri daca nu e mai bine ca aplicatzia ta sa foloseasca SQL Agent pentru a creea un plan de backup in loc sa ruleze comenzi de BACKUP direct din aplicatie. Un punct de pornire ar fi T-SQL sp_add_job sau SMO.

Despre 'recordul nr. N', problema este ca nu exista un asemenea concept intro baza de date relationala. Nici ca teorie (algebra), nici ca practica (B-tree). Singurul mod de a gasi 'recordul nr. N' este ca pur si simplu incepi sa numeri recordurile si sa te opresti la N (de unde si toate solutiile cu RWO_NUMBER() OVER...).
Dar asta nu inseamna ca totdeuna trebuie sa numeri 2 mil de recorduri ca sa afisezi pagina nr. 5000 :) Ma gindesc la cel putzin doua solutzii viabile:
- navigarea cu un dictionar-index: in loc sa afisezi 'pagina 1', 'pagina 2' etc si sa lasi utilizatorul sa navigheze la 'pagina 100', potzi afisa un index: 'A', 'B', ... 'Z'. click pe 'M' duce utilizatorul la pagina care contine primul record care incepe cu 'M'. SQL-ul corespunzator este foarte eficient, pur si simplu SELECT TOP ... WHERE key >= 'M'. Similar cu o carte de telefon, potzi creea indexul cu mai multe nivele (indexul A-Z te duce la un al doilea index unde se pot selectiona paginile 'MAA-MZZ' s.a.m.d). Este o solutie eficienta si foarte 'user-friendly', oricine prefera sa caute in cartea de telefon la pagina 'POP' pentru Popescu, nu la 'Pagina 234, unde sint Popestii'. Dezavantajul este ca este destul de complex de implementat si codul in general este specific, nu poate fi refolosit generic pentru orice tabela
- inserarea numarului de pagina in tabela. Pur si simplu fiecare record contine pagina in care trebuie afisat, setat la momentul cind record-ul este creat/schimbat. Atunci e extrem de simplu sa gasesti 'primul record din pagina N', penttru ca 'pagina N' este parte a cheii de index. Problema este ca acum aplicatia trebuie sa insereze valoarea corecta in coloana respectiva, o sarcina nu foarte simpla.

HTH,
~ Remus