Interogare (obiect) vs Interogare (procedura)

[Corvin]

Salut!...as dori sa pun si eu o intrebare ajutatoare pt cei care doresc sa dea raspunsuri pentru concurs, dar cum eu sunt mai ”sucit” decat altii doresc sa existe si o motivatie cat de cat in raspuns.

Intrebarea ar suna cam asa: Care metoda este mai benefica pentru o aplicatia de tip Access, utilizarea interogarilor, adica realizarea acestora prin grila QBE sau fereastra SQL (functie de tipul acestora) sau introducerea acestora in proceduri (in cadrul modulelor), si de ce?

[Corvin]

Raspunsul este extrem de simplu.
Chiar daca o interogare nu ruleaza continuu in cadrul unei aplicatii, ea exista ca si obiect, ceea ce face ca la un anumit numar de interogari (apreciabil, de altfel), aplicatia sa devina mai ”consistenta”, si evident ca acest lucru se repercuteaza ”negativ” in modul de functionare al aplicatiei. Pe de alta parte, daca interogarile sunt introduse in interiorul moduleleor prin cod VBA si daca aceste module sunt exportate in ceea ce se vrea o fi o biblioteca de functii, urmand ca mai apoi aplicatia sa realizeze o referinta la biblioteca de functii respectiva, atunci lucrurile se schimba, intrucat aplicatia (partea de program - front end) se micsoreaza si astfel aplicatia (per global) functioneaza mai rapid.

[Marin Zanfir]

Pe o tabela cu 10.250.689 de inregistrari am facut urmatoarele teste:

Am rulat urmatorul query:
Q_TVA:

Cod: Selectaţi tot

UPDATE PozitiiFacturiClienti SET PozitiiFacturiClienti.ProcentTVA = 24;


cu DoCmd.OpenQuery "Q_TVA", acNormal, acEdit
Timp de executie aprox. 124.5s

Executia codului:

Cod: Selectaţi tot

CurrentDb.Execute "UPDATE PozitiiFacturiClienti SET PozitiiFacturiClienti.ProcentTVA = 24;"


a durat aprox. 48,6s


Executia codului:

Cod: Selectaţi tot

CurrentProject.Connection.Execute "UPDATE PozitiiFacturiClienti SET PozitiiFacturiClienti.ProcentTVA = 24;"


a durat aprox. 47,4s

Executia codului:

Cod: Selectaţi tot

    Dim rs As DAO.Recordset
   
    Set rs = CurrentDb.OpenRecordset("PozitiiFacturiClienti", dbOpenTable)
    Do Until rs.EOF
        rs.Edit
        rs!ProcentTVA = 24
        rs.Update
        rs.MoveNext
    Loop
    rs.Close
    Set rs = Nothing


a durat aprox. 486s

Executia codului:

Cod: Selectaţi tot

    Dim rs As ADODB.Recordset
   
    Set rs = New ADODB.Recordset
    CurrentProject.Connection.Properties("Jet OLEDB:Max Locks Per File") = 20000
    rs.Open "PozitiiFacturiClienti", CurrentProject.Connection, adOpenKeyset, adLockOptimistic
    Do Until rs.EOF
        rs!ProcentTVA = 24
        rs.Update
        rs.MoveNext
    Loop
    rs.Close
    Set rs = Nothing


a durat aprox. 465s

Important. fara setarea optiuni MaxLocksPerFile a dat eroare.

Testarea am facut-o in aceleasi conditii cu Access 2003.

Concluziile cred ca sunt foarte clare.

[Corvin]

Consider ca nu am fost inteles corect. Nu m-am referit punctual la viteza de executie a interogarilor, ci la faptul ca o aplicatie in situatia in care este mai mica d.p.d.v. cantitativ, ca sa zic asa, functioneaza mai rapid. Se stie faptul ca un fisier de tip Access, indiferent ca este in format mai vechi, indiferent ca este in format nou, conserva in interiorul sau mai multe tipuri de obiecte (ex. tabele, interogari, formulare, macrocomenzi, module ) ceea ce face ca pe parcurs aplicatia sa devina mai consistenta, mai mare, de aceea se recomanda de catre specialisti, de regula, impartirea aplicatiei in doua parti, front-end (partea de program) si back-end (partea propriu-zisa de baza de date). Totusi, oricat am dori sa simplificam d.p.d.v. cantitativ aplicatia, lucrul acesta nu se poate face foarte mult, intrucat asa cum am spus in postul anterior, daca aplicatia contine foarte multe obiecte si aici ma refer punctual la interogari (am vazut aplicatie cu peste 100 de interogari), aceasta "atarna la cantar" cam mult. Evident ca cel care proiecteaza o aplicatie de dimensiuni medii, in mediul Access (Access-ul a fost proiectat ca un SGBD in special pentru baze de date mici si cel mult medii) la un moment dat va trebui, in opinie personala, sa faca un compromis intre "greutatea" unei aplicatii si viteza de executie a diferitelor componente. Cu toate ca ma indepartez putin de subiect, totusi am sa spun ca acesta a si fost unul dintre motivele pentru care o parte dintre proiectantii de aplicatii de baze de date aleg ca partea de programare sa se faca, spre exemplu, in Visual Basic.

[adof]

sal
putem vedea şi noi un program exemplu

[dinu]

Impresia mea este ca o baza de date (.mdb) oricat de mare ar fi, se deschide mult mai repede decat un fisier Excel. Practic in no-time.
Ca si cum toate operatiunile s-ar efectua direct pe hard, local, strict in functie de necesitati, fara sa fie nevie sa fie expandata toata baza de date, sau o parte semnificativa din ea. Ca si cum fisierul bazei de date nici nu ar fi nevoie sa fie "foarte deschis".

In VBA da. E mai bine de folosit un DoCmd.RunSQL, decat operatiuni cu seturi de inregistrari, pentru ca VBA-ul e intotdeauna interpretat mai greoi.
... Unele lucruri pot fi facute numai cu seturi de inregistrari (Recordset-uri).