Limitele numărului de rânduri dintr-o tabelă SQL Server

În plus față de toate cele de mai sus, care sunt recomandări grozave, m-am gândit că aș da un context mai mult pe punctul de index/performanță.

După cum sa menționat mai sus, nu este posibil să se dea un număr de performanță, în funcție de calitatea și numărul indiciilor dvs. performanța va fi diferită. De asemenea, depinde de ce operațiuni doriți să optimizați. Trebuie să optimizați inserțiile? sau sunteți mai preocupat de răspunsul la interogare?

Dacă sunteți cu adevărat preocupat de viteza de inserare, partiționarea, precum și o analiză FOARTE atentă index va fi cheia.

Recomandarea tabelului separat de Tom H este, de asemenea, o idee bună.

BrianV este corect. Este greu să dai o regulă, deoarece variază drastic pe baza modului în care vei folosi tabelul, cum este indexat, coloanele reale din tabel etc.

În ceea ce privește practicile obișnuite ... pentru mesele foarte mari, puteți lua în considerare împărțirea. Acest lucru ar putea fi util în special dacă descoperiți că pentru jurnalul dvs. vă interesează de obicei schimbările din ultima lună (sau 1 zi, 1 săptămână, 1 an, oricare). Ar putea apoi să arhivați porțiuni mai vechi ale datelor, astfel încât acestea să fie disponibile dacă este absolut necesar, dar nu vor fi în cale, deoarece aproape că nu veți avea nevoie de ea.

Un alt lucru care trebuie luat în considerare este să aveți un tabel de jurnal separat pentru fiecare tabelă reală, dacă nu intenționați să faceți acest lucru. Utilizând o singură tabelă de jurnal, este foarte dificil să lucrați cu ea. De obicei, trebuie să înregistrați informațiile într-un câmp de text liber, care este dificil de interogat și de procesat. De asemenea, este dificil să te uiți la date dacă ai un rând pentru fiecare coloană care a fost schimbat pentru că trebuie să faci o mulțime de conexiuni pentru a privi schimbările care au loc simultan.

Este adevărat că numărul de rânduri este limitat de spațiul de stocare disponibil.

Este greu să dai numere, deoarece depinde în mare măsură de hardware-ul serverului, configurația și cât de eficiente sunt interogările tale.

De exemplu, o instrucțiune simplu select va rula mai repede și va afișa o degradare mai mică decât o căutare completă sau proximitate ca numărul de rânduri crește.

Cu tabelele de audit, o altă abordare este de a arhiva datele o dată pe lună (sau săptămână, în funcție de cantitatea de date pe care le puneți în ea) sau cam asa ceva. În acest fel, dacă trebuie să recreați unele modificări recente cu datele proaspete, se poate face împotriva tabelelor mai mici și astfel mai repede (recuperarea din tabelele de audit este aproape întotdeauna o sarcină urgentă pe care am găsit-o!). Dar aveți în continuare datele avialabile în cazul în care vreți să vă întoarceți mai departe la timp.