Optimisation traitement sql

Bonjour je m'attaque aujourd'hui à de l'optimisation de mon application.
Bien qu'ayant lu la FAQ access concernant cette tâche, une question continue de me tarauder l'esprit:

Optimise ton plus les traitements en passant par du sql directe (update [table] set ...) ou bien en passant par les objets DAO.RECORDSET

exemple de code ci-dessus, lequel des traitements serait le lus optimisé et le plus rapide :
bloc 1

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Dim myRs As DAO.Recordset 'Begin the transaction myWrk.BeginTrans   'start an update throught the recordset Set myRs = myDb.OpenRecordset("Category") myRs.Filter = "category_id = " & Me.Id With myRs .Edit .Fields("Label") = Me.Label .Fields("Description") = Me.Description .Fields("TicketFlag") = Me.TicketFlag .Fields("UpdatedBy") = Me.UpdatedBy .Fields("UpdateDate") = Me.UpdateDate .Update End With   'commit the transaction myWrk.CommitTrans dbForceOSFlush   set myRs = nothing

---

vs


bloc 2

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Dim reqSQL As String   reqSQL = "update [category] set [label] = '" & param label & '" where category_id = 1 'Begin the transaction myWrk.BeginTrans   Docmd.runSQL(reqSQL) 'commit the transaction myWrk.CommitTrans dbForceOSFlush   set myRs = nothing

---

Je precise que pour un insert, il est dit que passer par un recordset prend le traitement plus rapide :

Citation:

---

L'utilisation d'un Recordset rend le traitement plus rapide.
Il est possible que la différence soit due au fait que le Recordset travaille avec la mémoire avant d'écrire sur le disque, alors que n requêtes provoquent n accès disque.

---

http://access.developpez.com/faq/?page=SQL#PerfReq

bonjour,

si tu avais des dizaines de milliers d'enregistrements à mettre à jour, on pourrait en discuter.

Mais là c'est pour mettre à jour 1 enregistrement si j'ai bien compris, on ne va pas chipoter pour des pouièmes de microsecondes, non ?:aie:

D'ailleurs tu as constaté une différence en essayant ?

je t'avouerai que c'est pour de la maj unique oui ^^. mais c'est pour dans le cadre d'évolution, après je n'ai pas effectué une comparaison des temps de calcul comme montré dans la faq, je le ferai si j'ai du temps de libre.

Après au niveau des traitements des données j'ai remarqué que les ordres sql direct étaient un peu plus long si je découple l'application (backend sur le réseau et front end sur le poste client), notamment pour les maj de lot.

Mais je donnerai un retour d'ici un mois si c'est toujours nécéssaire (même si je pense que l'update agis comme l'insert).

Dois-je marquer le poste comme résolu ?

Remarque pratique autre que je groupe ici (pour jne pas faire de multitude de discussion), j'ai remarqué que passer par le gestionnaire d'erreur de la base (champs null/indexés sans doublon, et remonté l'erreur capté) était plus rapide que de créer son propre gestionnaire d'erreur (une fonction qui vérifie si mes champs sont vides ou non), si jamais ca interesse quelqu'un.

Bonjour,

Citation:

---

Remarque pratique autre que je groupe ici (pour jne pas faire de multitude de discussion), j'ai remarqué que passer par le gestionnaire d'erreur de la base (champs null/indexés sans doublon, et remonté l'erreur capté) était plus rapide que de créer son propre gestionnaire d'erreur (une fonction qui vérifie si mes champs sont vides ou non), si jamais ca interesse quelqu'un.

---

Logique. Dans un cas ton moteur de base de données lève une erreur d'un autre coté tu vérifies tes champs avec un langage interprété. C'est forcément moins rapide.

Pour en revenir à tes interrogations, et je rejoins F-leb :
Modifier 1 record par-ci par-là, un Edit/Update suffit.
Modifier un ensemble de record il faut privilégie toujours la requête, le moteur de base de données sera toujours plus rapide, dans la mesure ; où tu n'écris pas une requête d'hérétique et/ou qu'elle n'utilise pas des clauses qui ne sont pas optimisables par le moteur -s'il en est capable.

Une règle que j'ai vérifié depuis de nombreuses années :
99% des problèmes se règlent avec SQL, le 1% restant est soit un problème de conception, soit une particularité métier.

Regarde le tuto sur l'optimisation des applications sur mon espace perso.

Cordialement,