Requete SQL vs boucle For

Bonsoir

je voudrais avoir votre avis.

je suis en train de faire une application où j'utilise une base SQLce, j'affiche mes requêtes dans un datagridview.

mais question est la suivante :

sachant que ma base pourra avoir plusieurs milliers lignes (car suivi de production), que dans une colonne j'ai un code défaut (pièce conforme si code défaut = 0, et mauvaise si != 0) et que je souhaite compter le nombre de pièces bonnes et le nombre de pièces mauvaises.

quelle sera la commande la plus rapide ? moins "gourmande" ?

faire une boucle FOR et un test du contenu de chaque cellule de la colonne de défauts pour incrémenter mes compteurs ?
ou bien faire 2 requêtes du style "SELECT * from maTable WHERE defaut = '0'" et "SELECT * from maTable WHERE defaut <> '0'" ?

merci

@++

KaloOopS

Bonsoir,

Je suis pas une experte mais personnellement je ferais une requête de type
SELECT COUNT(*) WHERE ...
La fonction COUNT() se charge de compter le nombre d'enregistrements.
Comme ça tout se fait directement dans ta base de données, probablement moins lourd qu'une incrémentation dans le programme.

Moi aussi je pencherais fortement pour la requête. :ccool:

Le test mérite d'être fait et donnera gagnantes de très loin les requêtes.

moi je prefere de faire une requete SQL ,
tu as tester le temps de reponse du requete et le temps du reponse du boucle for?

Citation:

---

Le test mérite d'être fait

---

+1

Citation:

---

et donnera gagnantes de très loin les requêtes.

---

Si tu as chargé toutes les données dans une Datable en mémoire bindée au dataGridView (et que tu utilises la propriété Filter du binding source pour afficher des extraits de la table), la boucle For sera me semble t'il plus efficace, surtout si le serveur est sur une autre machine.

Bonjour

Merci pour vos réponses nocturnes ... ;)

la tendance est donc à la requête, mais je vais essayer de faire un chrono entre les 2 pour voir.

Citation:

---

Si tu as chargé toutes les données dans une Datable en mémoire bindée au dataGridView

---

heu je sais pas :oops:, j'ai un truc du genre :

Code:

---

1 2 3 4 5 6

DataTable data = new DataTable();   SqlCeDataAdapter da = new SqlCeDataAdapter(maRequeteSelect, connectionString);   da.Fill(data);

---

sinon un "SELECT COUNT(*)" est plus rapide qu'un "SELECT *" ? ca demande moins de ressources ?

@++

KaloOopS

Je le ferais par requête pour une simple et bonne raison : je ne ramènerais certainement pas mes milliers de lignes dans ma datatable !

Si tu les affiches, je te conseille de mettre un pager et de ne ramener que celles qui seront affichées par la page en cours. Ensuite tu fais tes deux count pour avoir tes compteurs de pièces valides ou défectueuses.

Citation:

---

sinon un "SELECT COUNT(*)" est plus rapide qu'un "SELECT *" ? ca demande moins de ressources ?

---

Un SELECT * te renverra toutes les données correspondant au filtre. Tu serais obliger de faire une boucle (for par exemple) derrière pour les compter.

Le SELECT COUNT(*) ne te renverra qu'une seule valeur qui sera justement le compte du nombre de données ramenées par la requete correspondante, SELECT * dans ce cas là.
Le compte étant fait par le moteur SQL sans avoir besoin de charger l'ensemble des données, il sera de toute façon toujours plus rapide que tout autre solution qui nécessite un chargement des données en mémoire fusse-t-elle un BindingSource

d'une manière générale, quand on utilise un outil il est bien de connaitre le fonctionnement de celui ci

après il suffit de réfléchir à ce qui se passe dans chaque cas, en schématisant ca donne :

- select * de 1000 lignes avec 10 colonnes ramené dans un datagridview
il y a 10000 choses à lire, à faire transiter entre sql server et vb, et à écrire dans vb
ensuite faire une boucle sur les 1000 lignes pour compter le nombre qui est en défaut fait encore 1000 choses à lire
donc au final 11000 lectures et 10000 écritures

- select count(*) (...) where defaut
parcours des 1000 lignes directement dans la table, donc seulement 1000 choses à lire
si en plus tu mets un index sur la colonne defaut, le nombre de choses à lire peut tomber aux alentours de 10 je pense

donc d'un coté 10 e/s et de l'autre 20000 e/s
je pense que c'est vite vu ...


si par contre tu as besoin d'afficher toutes les lignes, tu peux te contenter de lire dans le datatable on est plus à ca près ^^

On à déja un peu tout dis mais je vais essayer de faire une synthese

1- Si seul le compte t'intéresse, alors il est infiniment preferable de faire deux select

Code:

---

1 2	select Count(*) from matable where monfiltre=0 select Count(*) from matable where monfiltre=1

---

Ou meme

Code:

---

select Count(*),Monfiltre from matable Group by Monfiltre

---

2- Si par contre tu tois Afficher des rows relatifs a monfiltre=1 ou 0, alors tu peux faire

Code:

---

1 2	DataView dvData=new DataView(data); dvData.RowFilter="Monfiltre=0";

---

Du coup le count de dvData s'ajuste automatiquemen et si tu met dvData en datasource d'un DGV tu affiche les row voulu;

Bien entendu, tu peux a tout moment adapter la valeur de RowFiler

Heu question bête, je fais comment pour récupérer la valeur du "select count(*)" :oops:

car si je fais un

Code:

---

1 2 3 4 5 6 7 8

DataTable data = new DataTable();   SqlCeDataAdapter da = new SqlCeDataAdapter(maRequeteSelect, connectionString);   da.Fill(data);   int result = data.Rows.Count;

---

ca me renvoie result = 1, normal y a qu'une réponse a ma requête, mais comment avoir sa valeur ?

DataTable ou DataSet ?

merci

@++

KaloOopS

Un exemple tout chaud et emballé !
A toi de completer

Code:

---

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

// ********************************************************************************* internal Object ExecuteScalar(string sql) { SqlConnection conn = OpenConnection(); if (conn == null) { return null; }   SqlCommand cmd = new SqlCommand(sql, conn);   object O; try { O = cmd.ExecuteScalar(); } catch (SqlException e) { this.isError = true; Message = e.Message; conn.Close(); return null; } conn.Close(); return O; }

---

il n'y a pas que les datasets et datatables dans la vie !

il y a des objets plus bas niveau comme dbcommand et dbdatareader, qui sont utilisées par le dataadapter

Olibara comment tu fais marcher ton code avec une base SqlCe ? :cry:

Pol :

Citation:

---

si vous ne comprenez pas ce que je dis, demandez à google

---

vais suivre les conseils de ta signature car je ne comprends pas ... pour l'instant ;)

si quelqu'un pouvait m'expliquer avec un bout de code "simple" comment récupérer la valeur d'un SELECT COUNT(*) dans un INT avec une base SqlCe, ce serait cool

merci

@++

KaloOopS

Je n'avais pas fait attention au code d'Olibara, je pensais qu'il était bon, mais effectivement je ne sais pas trop d'où il sort ce code.

Code:

---

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

SqlCeConnection cnn = new SqlCeConnection(connexionstring); SqlCeCommand cmd = cnn.CreateCommand(); cmd.CommandType = CommandType.Text; cmd.CommandText = "SELECT COUNT(*) FROM matable WHERE monfiltre=0";   cnn.Open();   int32 Resultat = Convert.ToInt32(cmd.ExecuteScalar());   cnn.Close(); cmd.Dispose(); cnn.Dispose();

---

La méthode ExecuteScalar, renvoie uniquement la première colonne de la première ligne du jeu de résultat.
Comme ici tu n'auras qu'une seule ligne d'une seule colonne, c'est plus rapide que de monter un dataReader.

Citation:

---

Je n'avais pas fait attention au code d'Olibara, je pensais qu'il était bon, mais effectivement je ne sais pas trop d'où il sort ce code.

---

Le code est bon et fonctionnel mais je n'avais pas vu qu'il s'agit de SQLCE

J'avais aussi dit qu'il fallait completer pour le contexte, car je n'ai extrait qu'une petite methode d'une classe Wrapper de commandes SQL que j'ai fait pour usage aussi bien en MySql qu'en MsSql

Et au passage j'utilise ce code tel quel dans une petite application mobile WindowsCE sans aucun souci

Merci sevy ca fonctionne,

désolé de créer un conflit entre vous avec mes questions :?

cependant je suis à présent confronté à un étrange phénomène :

j'ai ma table SqlCe qui a 1000 enregistrements de 11 colonnes (sans le id).

j'ai fait des chronos pour tester quelle requête/quelle tâche est la plus rapide avec le code suivant (test sur SELECT COUNT(*), SELECT *, boucle FOR) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

private void button2_Click(object sender, EventArgs e) { DateTime start = DateTime.UtcNow; SqlCeConnection cnn = new SqlCeConnection(connectionString); SqlCeCommand cmd = cnn.CreateCommand(); cnn.Open(); cmd.CommandType = CommandType.Text; cmd.CommandText = "SELECT COUNT(*) FROM " + tblSQL + " WHERE defaut = 0"; nbPieceOK = Convert.ToInt32(cmd.ExecuteScalar()); cmd.CommandText = "SELECT COUNT(*) FROM " + tblSQL + " WHERE defaut <> 0"; nbPieceNOK = Convert.ToInt32(cmd.ExecuteScalar()); cnn.Close(); cmd.Dispose(); cnn.Dispose(); DateTime end = DateTime.UtcNow; double diff = diffTime(start, end); listBox1.Items.Add(diff);   start = DateTime.UtcNow; nbPieceOK = ExecuteSelect("SELECT * FROM " + tblSQL +" WHERE defaut = 0", false, data, ""); nbPieceNOK = ExecuteSelect("SELECT * FROM " + tblSQL + " WHERE defaut <> 0", false, data, ""); end = DateTime.UtcNow; diff = diffTime(start, end); listBox1.Items.Add(diff);   start = DateTime.UtcNow; for (int i = 0; i < dgView1.Rows.Count; i++) { int defautValue = Convert.ToInt16(dgView1.Rows[i].Cells[9].Value.ToString()); if (defautValue == 0) nbPieceOK++; else nbPieceNOK++; } end = DateTime.UtcNow; diff = diffTime(start, end); listBox1.Items.Add(diff); }

---

la fonction pour faire le chrono est :

Code:

---

1 2 3 4 5 6 7 8

private double diffTime(DateTime start, DateTime end) { double result = 0; long diff = end.Ticks - start.Ticks; result = (diff / 10000.0); return result; }

---

le "ExecuteSelect" est une fonction faisant un select * from ... via SqlCeDataAdapter et DataTable.

les chronos sont affichés dans une listbox, et là le verdict est vraiment étonnant !!!

avec mon PC (AMD 3000+, 1.5 Go RAM, XP SP3), je suis pour 1000 enregistrements entre :
- 15.625 et 31.25 ms pour le SELECT COUNT(*)
- 46.875 et 78.125 ms pour le SELECT *

mais je suis entre :

- 0 et 15.625 ms pour la boucle FOR !!!! 8O8O

étonnant non ?? ca veut dire que la boucle FOR est plus rapide que les requêtes SQL, si le datagridview est déjà rempli et visible.

allez question subsidiaire :

pourquoi mes chronos sont toujours des multiples de 15.625 ms ?? est-ce lié au performances du PC ou bien est-ce le DateTime.UtcNow qui n'est pas plus précis ? (j'ai le même multiple si je fais DateTime.Now).

Merci

@++

KaloOopS

Tout a fait normal que ta boucle for soit plus rapide qu'une requete SQL
Mais de toute facon tu dois ajouter au temps de cette boucle le temps SQL nécessaire a charger les donnée utiles a la boucle

D'autre par l'erreur classique et récurrente est de considerer le datagridview comme un container de données permettant toute les manipulations

Un datagridview est AVANT TOUT une vue !
Les manipulations programatiques doivent se faire sur le modele de donnée sous-jacent (datatable, liste, etc) !

Pas de conflit, j'avais d'abord cru que son code était bon mais quand tu as dit que tu ne le comprenais j'ai effectivement cru qu'il avait donné l'implémentation de ExecuteScalar plutôt qu'un exemple d'utilisation. Mais au final, il a donné un code proche de celui que j'ai donné ensuite.

Pour tes tests, les valeurs pour le For ne sont pas juste car tu zappe toute la partie ouverture de la connexion, chargement des données dans de DataAdapter, etc ...
Malgré cela, même uniquement pour la partie boucle For je m'attendait à des résultats plus élevés.

Concernant ExecuteSelect, on ne sait pas comment est fait la fonction, mais si tu passe par un datareader et une boucle For, tu devrais être dans les mêmes temps qu'avec le DataAdapter.

Concernant le 15,625ms, le chiffre est surprenant. Il devrait plutôt être de 18.2ms.
18.2ms étant la valeur du tick d'horloge "temps réel", celle qui donne l'heure.

Dans la réalité, je pense que ton SELECT COUNT(*) doit être en dessous des 15ms, mais par manque de précision de la mesure, tu n'a pas la valeur réelle.