Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[WD10-62f] conception théorique de requête SQL

9 réponses
Avatar
JeAn-PhI
bonjour

je dois faire un relévé client mais avec certaines contrainte de dev.
j'explique : le relevé se réfère à un client qui peut ou non avoir des
factures et des avoirs pour faire cela je ne dois pas utiliser de
requêtes complexes (multi jointure, imbrication, etc.)

j'ai commencé par faire ma fenêtre de sélection de client(tous ou un
client au choix) avec un critère sur le type de produit(tous ou un type
de produit) que l'on facture

donc mon état est basé sur un requête simple de sélection de client
avec un rupture programmé (pour ne prendre en compte que les clients
qui doivent avoir au moins un facture ou un avoir) si le client n'a ni
l'un ni l'autre il ne doit pas appraitre sur le relevé

donc lors de la lecture de la source (portion de code de l'état) je
dois faire un intérogation si le client possède au moins un facture ou
un avoir selon un critère de période de date et de type de produit et
c'est là la question :

en théorie quel est le plus rapide faire une requête qui compte les
factures selon les critères si < 0 alors compter les avoirs si < 0
alors passé au client suivant sinon nb facture > 0 alors prendre le
client OU faire une sélection sans compter

en résumé compter ou sélectionné uniquement ?

merci

--
Cordialement JeAn-PhI

9 réponses

Avatar
Albert
On 25 juil, 10:43, JeAn-PhI wrote:
bonjour

je dois faire un relévé client mais avec certaines contrainte de dev.
j'explique : le relevé se réfère à un client qui peut ou non avoi r des
factures et des avoirs pour faire cela je ne dois pas utiliser de
requêtes complexes (multi jointure, imbrication, etc.)

j'ai commencé par faire ma fenêtre de sélection de client(tous ou un
client au choix) avec un critère sur le type de produit(tous ou un type
de produit) que l'on facture

donc mon état est basé sur un requête simple de sélection de clie nt
avec un rupture programmé (pour ne prendre en compte que les clients
qui doivent avoir au moins un facture ou un avoir) si le client n'a ni
l'un ni l'autre il ne doit pas appraitre sur le relevé

donc lors de la lecture de la source (portion de code de l'état) je
dois faire un intérogation si le client possède au moins un facture ou
un avoir selon un critère de période de date et de type de produit et
c'est là la question :

en théorie quel est le plus rapide faire une requête qui compte les
factures selon les critères si < 0 alors compter les avoirs si < 0
alors passé au client suivant sinon nb facture > 0 alors prendre le
client OU faire une sélection sans compter

en résumé compter ou sélectionné uniquement ?

merci

--
Cordialement JeAn-PhI



Bonjour,

Si j'ai bien compris pourquoi ne pas vous orienter directement vers
une requete de sélection et de regroupement
des enregistrements qui corresponderaient aux critères des
parametres.mis en places ?


Cordialement

Albert
Avatar
JeAn-PhI
Albert a utilisé son clavier pour écrire :
On 25 juil, 10:43, JeAn-PhI wrote:
bonjour

je dois faire un relévé client mais avec certaines contrainte de dev.
j'explique : le relevé se réfère à un client qui peut ou non avoir des
factures et des avoirs pour faire cela je ne dois pas utiliser de
requêtes complexes (multi jointure, imbrication, etc.)

j'ai commencé par faire ma fenêtre de sélection de client(tous ou un
client au choix) avec un critère sur le type de produit(tous ou un type
de produit) que l'on facture

donc mon état est basé sur un requête simple de sélection de client
avec un rupture programmé (pour ne prendre en compte que les clients
qui doivent avoir au moins un facture ou un avoir) si le client n'a ni
l'un ni l'autre il ne doit pas appraitre sur le relevé

donc lors de la lecture de la source (portion de code de l'état) je
dois faire un intérogation si le client possède au moins un facture ou
un avoir selon un critère de période de date et de type de produit et
c'est là la question :

en théorie quel est le plus rapide faire une requête qui compte les
factures selon les critères si < 0 alors compter les avoirs si < 0
alors passé au client suivant sinon nb facture > 0 alors prendre le
client OU faire une sélection sans compter

en résumé compter ou sélectionné uniquement ?

merci

--
Cordialement JeAn-PhI



Bonjour,

Si j'ai bien compris pourquoi ne pas vous orienter directement vers
une requete de sélection et de regroupement
des enregistrements qui corresponderaient aux critères des
parametres.mis en places ?


Cordialement

Albert



justement c'est ce que je ne dois pas faire comme type de requête
(contrainte imposée)

--
Cordialement JeAn-PhI
Avatar
Jacques Bratières
Le Wed, 25 Jul 2007 14:06:00 +0200, JeAn-PhI a écrit:

Albert a utilisé son clavier pour écrire :
On 25 juil, 10:43, JeAn-PhI wrote:
bonjour
je dois faire un relévé client mais avec certaines contrainte de dev.
j'explique : le relevé se réfère à un client qui peut ou non avoir des
factures et des avoirs pour faire cela je ne dois pas utiliser de
requêtes complexes (multi jointure, imbrication, etc.)
j'ai commencé par faire ma fenêtre de sélection de client(tous ou un
client au choix) avec un critère sur le type de produit(tous ou un type
de produit) que l'on facture
donc mon état est basé sur un requête simple de sélection de client
avec un rupture programmé (pour ne prendre en compte que les clients
qui doivent avoir au moins un facture ou un avoir) si le client n'a ni
l'un ni l'autre il ne doit pas appraitre sur le relevé
donc lors de la lecture de la source (portion de code de l'état) je
dois faire un intérogation si le client possède au moins un facture ou
un avoir selon un critère de période de date et de type de produit et
c'est là la question :
en théorie quel est le plus rapide faire une requête qui compte les
factures selon les critères si < 0 alors compter les avoirs si < 0
alors passé au client suivant sinon nb facture > 0 alors prendre le
client OU faire une sélection sans compter
en résumé compter ou sélectionné uniquement ?
merci
--
Cordialement JeAn-PhI



Bonjour,

Si j'ai bien compris pourquoi ne pas vous orienter directement vers
une requete de sélection et de regroupement
des enregistrements qui corresponderaient aux critères des
parametres.mis en places ?


Cordialement

Albert



justement c'est ce que je ne dois pas faire comme type de requête
(contrainte imposée)



Normalement le plus rapide est une requête traitée complètement en non
procédural par le moteur
SGBD , donc une requête SQL pure.



--
J.Bratières
Avatar
JeAn-PhI
Jacques Bratières a exprimé avec précision :
Le Wed, 25 Jul 2007 14:06:00 +0200, JeAn-PhI a écrit:

Albert a utilisé son clavier pour écrire :
On 25 juil, 10:43, JeAn-PhI wrote:
bonjour
je dois faire un relévé client mais avec certaines contrainte de dev.
j'explique : le relevé se réfère à un client qui peut ou non avoir des
factures et des avoirs pour faire cela je ne dois pas utiliser de
requêtes complexes (multi jointure, imbrication, etc.)
j'ai commencé par faire ma fenêtre de sélection de client(tous ou un
client au choix) avec un critère sur le type de produit(tous ou un type
de produit) que l'on facture
donc mon état est basé sur un requête simple de sélection de client
avec un rupture programmé (pour ne prendre en compte que les clients
qui doivent avoir au moins un facture ou un avoir) si le client n'a ni
l'un ni l'autre il ne doit pas appraitre sur le relevé
donc lors de la lecture de la source (portion de code de l'état) je
dois faire un intérogation si le client possède au moins un facture ou
un avoir selon un critère de période de date et de type de produit et
c'est là la question :
en théorie quel est le plus rapide faire une requête qui compte les
factures selon les critères si < 0 alors compter les avoirs si < 0
alors passé au client suivant sinon nb facture > 0 alors prendre le
client OU faire une sélection sans compter
en résumé compter ou sélectionné uniquement ?
merci
--
Cordialement JeAn-PhI



Bonjour,

Si j'ai bien compris pourquoi ne pas vous orienter directement vers
une requete de sélection et de regroupement
des enregistrements qui corresponderaient aux critères des
parametres.mis en places ?


Cordialement

Albert



justement c'est ce que je ne dois pas faire comme type de requête
(contrainte imposée)



Normalement le plus rapide est une requête traitée complètement en non
procédural par le moteur
SGBD , donc une requête SQL pure.



je comprend bien pour l'avoir déjà fait mais aujourd'hui il faut que je
fasse avec des requêtes simplistes ou sans donc j'opte pour les
requêtes simplistes et du code
ce que j'aimerais savoir c'est qui est en théorie plus rapide :
- une requête de type select puis test si il existe au moins un enreg
- une requête de type count puis test si > 0

--
Cordialement JeAn-PhI
Avatar
Pierre BOUSQUET
une requete du style SELECT TOP 1 est bcp plus rapide

Après mûre réflexion, JeAn-PhI a écrit :
Jacques Bratières a exprimé avec précision :
Le Wed, 25 Jul 2007 14:06:00 +0200, JeAn-PhI a écrit:

Albert a utilisé son clavier pour écrire :
On 25 juil, 10:43, JeAn-PhI wrote:
bonjour
je dois faire un relévé client mais avec certaines contrainte de dev.
j'explique : le relevé se réfère à un client qui peut ou non avoir des
factures et des avoirs pour faire cela je ne dois pas utiliser de
requêtes complexes (multi jointure, imbrication, etc.)
j'ai commencé par faire ma fenêtre de sélection de client(tous ou un
client au choix) avec un critère sur le type de produit(tous ou un type
de produit) que l'on facture
donc mon état est basé sur un requête simple de sélection de client
avec un rupture programmé (pour ne prendre en compte que les clients
qui doivent avoir au moins un facture ou un avoir) si le client n'a ni
l'un ni l'autre il ne doit pas appraitre sur le relevé
donc lors de la lecture de la source (portion de code de l'état) je
dois faire un intérogation si le client possède au moins un facture ou
un avoir selon un critère de période de date et de type de produit et
c'est là la question :
en théorie quel est le plus rapide faire une requête qui compte les
factures selon les critères si < 0 alors compter les avoirs si < 0
alors passé au client suivant sinon nb facture > 0 alors prendre le
client OU faire une sélection sans compter
en résumé compter ou sélectionné uniquement ?
merci
--
Cordialement JeAn-PhI



Bonjour,

Si j'ai bien compris pourquoi ne pas vous orienter directement vers
une requete de sélection et de regroupement
des enregistrements qui corresponderaient aux critères des
parametres.mis en places ?


Cordialement

Albert



justement c'est ce que je ne dois pas faire comme type de requête
(contrainte imposée)



Normalement le plus rapide est une requête traitée complètement en non
procédural par le moteur
SGBD , donc une requête SQL pure.



je comprend bien pour l'avoir déjà fait mais aujourd'hui il faut que je fasse
avec des requêtes simplistes ou sans donc j'opte pour les requêtes simplistes
et du code
ce que j'aimerais savoir c'est qui est en théorie plus rapide :
- une requête de type select puis test si il existe au moins un enreg
- une requête de type count puis test si > 0



--
Pierre BOUSQUET

" Ne me dites pas que ce problème est difficile.
S'il n'était pas difficile, ce ne serait pas un problème. "
Avatar
JeAn-PhI
Il se trouve que Pierre BOUSQUET a formulé :
une requete du style SELECT TOP 1 est bcp plus rapide



[CUT]
voici le code d'exe de la req :

R_TEST.pDateDeb = "20050101"
R_TEST.pDateFin = "20051231"
szHeureDeb est une Heure = HeureSys()
SI PAS HExécuteRequête(R_TEST,hRequêteDéfaut) ALORS
Erreur("exe req",HErreurInfo())
FIN
szHeureFinExec est une Heure = HeureSys()
HLitPremier(R_TEST)
SI PAS HEnDehors(R_TEST) ALORS
Trace("enreg trouvé ")
FIN
szHeureFin est une Heure = HeureSys()
Trace("temps exec :
"+HeureVersChaine(EntierVersHeure(HeureDifférence(szHeureDeb,szHeureFinExec)),"HH:MM:SS:CC"))
Trace("temps total :
"+HeureVersChaine(EntierVersHeure(HeureDifférence(szHeureDeb,szHeureFin)),"HH:MM:SS:CC"))

après qq test sur un fichier de 26000 enregs j'obtiens :

req de type count : 1s 25
SELECT COUNT(*) AS Comptage_1
FROM MonFichier
WHERE MonFichier.DATE BETWEEN {pDateDeb} AND {pDateFin}

req de type select : 0s 05
SELECT MonFichier.ID
FROM MonFichier
WHERE MonFichier.DATE BETWEEN {pDateDeb} AND {pDateFin}

req de type select top 1 : 1s 80
SELECT TOP 1 MonFichier.ID
FROM MonFichier
WHERE MonFichier.DATE BETWEEN {pDateDeb} AND {pDateFin}

en fait le but est de savoir si la req retourne un résultat et à
postériori le select est plus rapide pour l'utilisation que je veux en
faire

merci à tous

--
Cordialement JeAn-PhI
Avatar
Pierre BOUSQUET
étrange que le TOP 1 soit moins rapide...

JeAn-PhI a émis l'idée suivante :
Il se trouve que Pierre BOUSQUET a formulé :
une requete du style SELECT TOP 1 est bcp plus rapide



[CUT]
voici le code d'exe de la req :

R_TEST.pDateDeb = "20050101"
R_TEST.pDateFin = "20051231"
szHeureDeb est une Heure = HeureSys()
SI PAS HExécuteRequête(R_TEST,hRequêteDéfaut) ALORS
Erreur("exe req",HErreurInfo())
FIN
szHeureFinExec est une Heure = HeureSys()
HLitPremier(R_TEST)
SI PAS HEnDehors(R_TEST) ALORS
Trace("enreg trouvé ")
FIN
szHeureFin est une Heure = HeureSys()
Trace("temps exec :
"+HeureVersChaine(EntierVersHeure(HeureDifférence(szHeureDeb,szHeureFinExec)),"HH:MM:SS:CC"))
Trace("temps total :
"+HeureVersChaine(EntierVersHeure(HeureDifférence(szHeureDeb,szHeureFin)),"HH:MM:SS:CC"))

après qq test sur un fichier de 26000 enregs j'obtiens :

req de type count : 1s 25
SELECT COUNT(*) AS Comptage_1
FROM MonFichier
WHERE MonFichier.DATE BETWEEN {pDateDeb} AND {pDateFin}

req de type select : 0s 05
SELECT MonFichier.ID
FROM MonFichier
WHERE MonFichier.DATE BETWEEN {pDateDeb} AND {pDateFin}

req de type select top 1 : 1s 80
SELECT TOP 1 MonFichier.ID
FROM MonFichier
WHERE MonFichier.DATE BETWEEN {pDateDeb} AND {pDateFin}

en fait le but est de savoir si la req retourne un résultat et à postériori
le select est plus rapide pour l'utilisation que je veux en faire

merci à tous



--
Pierre BOUSQUET

" Ne me dites pas que ce problème est difficile.
S'il n'était pas difficile, ce ne serait pas un problème. "
Avatar
JeAn-PhI
Pierre BOUSQUET avait soumis l'idée :
étrange que le TOP 1 soit moins rapide...



[CUT]
je pense qu'il doit exécuter la req puis ne retourné que le 1er enreg
j'ai oublié de préciser que ma rubrique date n'est pas clé pour le test
effectué

--
Cordialement JeAn-PhI
Avatar
Pierre BOUSQUET
ah ben voila c'est ca !!

JeAn-PhI avait prétendu :
Pierre BOUSQUET avait soumis l'idée :
étrange que le TOP 1 soit moins rapide...



[CUT]
je pense qu'il doit exécuter la req puis ne retourné que le 1er enreg
j'ai oublié de préciser que ma rubrique date n'est pas clé pour le test
effectué



--
Pierre BOUSQUET

" Ne me dites pas que ce problème est difficile.
S'il n'était pas difficile, ce ne serait pas un problème. "