Az ado és a dao használata masszív adatok importálásához, a puha építés mechanikájához
Mivel az ügyfélszámítógépek teljesítménye most magas, több millió sor van a helyi adatbázisban
nem probléma az ilyen mennyiségek feldolgozásához, de akkor is szűk keresztmetszetet hozhat létre
információcsere.
Különleges példa az adatok helyi távoli forrásból való importálása helyi MS Access adatbázisba. A probléma feltételei szerint a lehető legnagyobb mértékben el kell távolítani az adatforrástól. Nem tudjuk előre, hogy a felhasználó hogyan szinkronizálja adatbázisát. Válogatás a MS Access, mint egy helyi adatbázis szintén nem egy tétel, a népszerűsége ellenére „motor” és a könnyű telepítés, vándorolnak az irányt MS SQL Express vagy a Firebird. Ezért el kell távolítani a vevőtől.
Az MS Access esetében a legnyilvánvalóbb lehetőség az, hogy az ADO / ADO.Net-t a legfontosabb technológiának tekintsék az adatok eléréséhez a Windows rendszerben. Az ODBC kevésbé nyilvánvaló. Még kevésbé "emlékezett" opció - DAO, bár kissé nagyobb sebességet biztosít a JET-hez (MS
Hozzáférés) és az Excel.
adCmdTable (CommandType for Recordset)
A nyilvántartásokat kötegelt módban mentették 10 ezer rekordidővel.
Cél. UpdateBatch # 40; adAffectAll # 41; ;
Eredmények (ellenőrizheti őket, ha a számítógépén próbatestet futtat):
ADO
Eltöltött idő: 17.53 mp
1000 rekordra eltöltött idő: 0.04 mp
DAO
Eltöltött idő: 12,56 mp
Az 1000 rekordra eltöltött idő: 0.03 mp
Úgy tűnik, hogy ha több százalékot szeretne nyerni - vegye be a DAO-t. De ne ugorj le következtetésekre. Ha a sebesség mellett más kritériumok is vannak, akkor a választás kevésbé nyilvánvaló.
Először is, az ADO gyorsasága a gyakorlatban ugyanolyan nagy - másodpercenként több tízezer rekord. Biztos vagyok benne, hogy a legtöbb esetben ez elég lesz a feladathoz.
Harmadszor, maga a forrás is sokkal lassabban tud adatot szolgáltatni, mint amilyet a vevő kész feldolgozni. Ez például akkor lehetséges, ha szinkronizálást végzünk egy internetes szolgáltatáson keresztül. Vagyis az optimalizálást igénylő szűk keresztmetszet nem adatírás, hanem továbbítás.
kiegészítés
A Delphi borítás alatt ADO mint TCustomADODataSet és leszármazottai (TADOQuery, TADOTable stb) van kellemetlen funkció - lassítja navigációt a bejegyzések és mezők, viszonylag nagy számban. Szerencsére ez csak nagyméretű DataSet méretekkel - több tízezer bejegyzéssel - és statikus kurzorral érhető el az ügyfélen.
Egy ilyen tipikus feldolgozási ciklusban jelentős lassulás van, és fokozatosan növekszik (megfigyelések szerint logaritmikusan). Esetünkben a feldolgozási sebesség másodpercenként nem haladta meg az 1000 rekordot. Lépjen ki a helyzetből - használja közvetlenül az ADO rekordhoz való hozzáférést.
A sebesség így nagyságrenddel növekszik, másodpercenként több tízezer rekord görgetéséhez.
Ellenőriztem az adatok importálásának módját - ez remekül működik. De van egy nagy BUT.
Hogyan kell kezelni a másolatokat?
Tegyük fel, hogy már több rekord van a táblázatban. Az egyik mezőnek egyedi indexe van.
Most 10 000 rekordot próbálunk importálni. És ezek közül a feljegyzések között van egy,
amely az index duplikátumának megjelenéséhez vezet.
Hogyan hagyhatja el ezt a rekordot, hogy a fennmaradó 9999 be legyen helyezve?
Két fő megoldás létezik:
- ellenőrizze a behelyezést a behelyezés előtt
- ellenőrizze a BEÁLLÍTÁS után
Ellenőrizze a művelet során, mert kizárt ez csökkenti a csomagbetét sebességét.
A beillesztés előtti ellenőrzés például olyan adatforrásra irányuló kérelem, amelyben kizárja a másolatokat
Ellenőrizze behelyezése után (helyezze maga is gyorsabb): csak meg kell, hogy távolítsa el az ideiglenes kulcsot (integritási megszorítás vagy egyedi index), majd helyezze bejegyzések elemzésére, megszüntetésére másolatokat, és újra a gombot.