Deoarece puterea computerelor client este acum mare, atunci milioane de rânduri în baza de date locală sunt deja
nu reprezintă o problemă pentru procesarea unor astfel de volume, dar poate crea o strangulare când
schimb de informații.
Un exemplu special este importul de date într-o bază de date locală MS Access de la o sursă de la distanță. Sub problema ar trebui să fie posibil să ignore sursa de date. Nu știm în avans modul în care utilizatorul își va sincroniza baza de date. Selectarea MS Access ca o bază de date locală nu este, de asemenea, un postulat, în ciuda popularității „motor“ și ușurința de desfășurare, pot migra în direcția MS SQL Express sau FireBird. Prin urmare, este necesar să se abțină de la receptor.
Pentru MS Access, opțiunea cea mai evidentă este utilizarea ADO / ADO.Net ca tehnologie cheie pentru accesarea datelor în Windows. ODBC este mai puțin evidentă. Chiar mai puțin "amintit" opțiunea - DAO, deși oferă o viteză ușor mai mare atunci când lucrează cu JET (MS
Acces) și Excel.
adCmdTable (CommandType for Recordset)
Înregistrările au fost salvate în modul lot, cu un interval de 10 mii de înregistrări.
Țintă. UpdateBatch # 40; adAffectAll # 41; ;
Rezultate (le puteți verifica prin rularea unui test pe computer):
ADO
Timpul scurs: 17,53 sec
Timpul scurs la 1000 de înregistrări: 0,04 sec
DAO
Timpul scurs: 12,56 sec
Timpul scurs la 1000 înregistrări: 0,03 sec
Se pare că dacă doriți să câștigați mai multe procente - luați DAO. Dar nu sari la concluzii. Dacă în plus față de viteză aveți și alte criterii, alegerea devine mai puțin evidentă.
În primul rând, viteza ADO în practică este la fel de mare - zeci de mii de înregistrări pe secundă. Sunt sigur că, în cele mai multe cazuri, acest lucru va fi suficient pentru sarcină.
În al treilea rând, însăși sursa de date poate fi dat un ritm mult mai lent decât cel cu care receptorul este gata să le proceseze. Acest lucru este posibil, de exemplu, atunci când sincronizați printr-un serviciu web pe Internet. Adică, blocajele care necesită optimizare nu vor fi scrierea de date, ci transmiterea.
plus
În Delphi înveliș peste ADO ca TCustomADODataSet și descendenții (TADOQuery, TADOTable etc.) are caracteristica neplăcută - încetinește de navigare prin înregistrările și câmpurile cu un număr relativ mare de ele. Din fericire, ea apare numai la dimensiuni mai mari, setul de date - zeci de mii de intrări - și un cursor statică pe client.
Într-un astfel de ciclu de prelucrare tipic, se înregistrează o încetinire semnificativă și crește treptat (conform observațiilor, logaritmic). În cazul nostru, viteza de procesare nu a depășit 1000 de înregistrări pe secundă. Ieșiți din situație - utilizați direct accesul la setul de înregistrări ADO.
Viteza crește astfel cu un ordin de mărime pentru a derula zeci de mii de înregistrări pe secundă.
Am verificat metoda de import a datelor - funcționează excelent. Dar există o mare BUT.
Cum să rezolvați duplicatele?
Să presupunem că există deja mai multe înregistrări în tabel. Unul dintre câmpuri are un indice unic.
Acum încercăm să importăm, de exemplu, 10.000 de înregistrări. Și printre aceste înregistrări există una,
ceea ce va duce la apariția unui duplicat al indicelui.
Cum să ignorați această înregistrare, astfel încât restul de 9999 să fie introduse?
Există două soluții principale:
- verificați inserarea înainte de introducere
- verificați după inserare
Verificarea în timpul operației este exclusă, deoarece aceasta va degrada viteza insertului de pachete.
O verificare pre-inserare este, de exemplu, o cerere către o sursă de date în care excludeți duplicate
Verificarea după inserare (inserția însăși poate fi mai rapidă): trebuie doar să eliminați cheia temporară (constrângere de integritate sau indice unic) și, după analiză, să analizați înregistrările, să excludeți duplicatele și să recreați cheia.
Articole similare
Trimiteți-le prietenilor: