Discussion :

[Spinx]

Bonjour,
J'ai une table Articles dans ma base de données qui contient les colonnes : codeArticle, libarticle, prixArticle et ordrePrix (voir ci-joint). Je veux une requête ou code source sous Windev qui permet de mettre à jour la colonne ordreArticle de cette façon,
Pour un code article donné, la ligne dont le prix est le 1er moins disant, la colonne ordre = 1 , la ligne dont le prix est le 2ème moins disant, la colonne ordre = 2, la ligne dont le prix est le 3ème moins disant, la colonne ordre = 3
Voir ci-joint un exemple comment cette colonne sera remplie.
Merci d'avance pour votre aide

[rompetit]

Bonjour,
Merci d'avance pour votre aide

Bonjour,

https://doc.pcsoft.fr/fr-FR/?3074035

De rien.

[Voroltinquo]

Bonjour,
Une solution assez bourrin
1-Récupérer la liste des prix triés sur prix via un SELECT DISTINCT. Prix doit être indexé.
2-Remplir un tableau (tabPrix) de STPrix avec le résultat de la requête via FichierVersTableau

Code txt :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
STPrix : structure
{
     m_moPrix : monétaire
}

3-A chaque affichage d'une ligne, rechercher le prix de l'article dans tabPrix. Le résultat correpond à l'ordre du prix
4-Afficher ordre

[fred1599]

Hello,

Je veux une requête ou code source sous Windev qui permet de mettre à jour la colonne ordreArticle de cette façon

Vous n'aurez pas grand chose tant que vous aurez pas mis un peu la main dans le code, et que vous présentiez un début de travail personnel. Comment allez vous contrôler les informations que l'on vous donne ? Comprenez vous le WLangage ?

[fred1599]

1-Récupérer la liste des prix triés sur prix via un SELECT DISTINCT

Donc si je vous comprend bien, si vous avez 50 000 codeArticle différents, cela exécutera 50 000 requêtes SELECT DISTINCT individuelles ?

Et si je vous suis, votre approche conserve l'anti-pattern HModifie dans la boucle, générant 1 million d'écritures réseau individuelles ?

Si vous êtes d'accord avec cela, je vous invite à lire cet article : https://blog.jooq.org/the-performanc...bulk-updating/

Si non, je veux bien un peu d'éclaircissement

[Voroltinquo]

Donc si je vous comprend bien

Justement, non, il n'y a qu'une requêt SELECT Distinc qui récupère l'ENSEMBLE des prix triès des 50000 articles.
La requête est en amont et la recherche du prix de chaque article se fait sur le résultat de cette requête. Pour remplir la colonne jaune, il faut bien trouver le n° d'ordre du prix.
Dans l'exemple 1900 est le prix n° 1, 2100 le n°2, 2500 le n°3, 3000 le n°4 ...
L'algo simplifié donnerai

Code txt :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Récupérér tous le Prix triés par ordre croissant
POUR CHAQUE Article
     Afficher Article
     Récupérer n° Ordre du prix
     Afficher N° d'ordre
FPOUR

J'ai simplement étoffé cet algo par des pistes. Il va de soit qu'il serait abérrant d'éxécuter la requête à chaque affichage de ligne, ou pire, comme on le vois souvent de remplir la colonne à postériori. Cerise sur le gâteau en exécutant la requête pour chaque ligne.

[fred1599]

Cette solution, telle que décrite (avec une seule requête SELECT DISTINCT globale), ne répond pas à la contrainte la plus importante du cahier des charges : le partitionnement par codeArticle.

Étape 1 : Le tabPrix Global

La requête SELECT DISTINCT prixArticle FROM Articles ORDER BY prixArticle va renvoyer un tableau global de tous les prix uniques de la base.
Le tabPrix en mémoire ressemblera à ceci :

tabPrix[1] = 1,40
tabPrix[2] = 1,90
tabPrix[3] = 2,10
tabPrix[4] = 2,20
tabPrix[5] = 3,00
... (etc.)


Étape 2 : Le Traitement

L'algorithme propose de boucler sur chaque ligne et de chercher le prix dans tabPrix pour trouver le rang. Voyons ce qui se passe :

Ligne à traiter : { codeArticle: "FOB001", prixArticle: 1,90 }
Recherche : TableauRecherche(tabPrix, 1.90)Résultat : L'index 2 est trouvé.
Rang assigné : 2
Rang attendu : 1
Conclusion : → ÉCHEC.
Ligne à traiter : { codeArticle: "FOB0011", prixArticle: 2,10 }
Recherche : TableauRecherche(tabPrix, 2.10)Résultat : L'index 3 est trouvé.
Rang assigné : 3
Rang attendu : 2
Conclusion : → ÉCHEC.

Le problème est que cette méthode calcule un rang de prix global (ou "Overall Rank") sur l'ensemble de la base, alors que le besoin est de calculer un rang de prix local (un "Partition Rank"), propre à chaque groupe codeArticle.
Le rang pour FOB001 doit recommencer à 1, et le rang pour FOB0011 doit également recommencer à 1.
Votre approche serait valide uniquement s'il n'y avait qu'un seul codeArticle dans toute la table. Puisque vous en avez 50 000, elle ne fonctionnera pas.

N'aurai-je encore pas compris vos étapes ?

[Voroltinquo]

En effet je n'ai pas pris en compte le couple Ref/Prix.
En continuant dans le bourrin, on peut dans ce cas requêter sur Ref/Prix triés par ordre croissant, puis renprir un tableau associatif de tableau de monétaire (indexé sur la ref) e.g. taRefPrix.
Lors de l'affichage, il suffira de récupérer le tableau corespondant à la ref tabPrix:=taRfPrix[Ref] puis de faire la recherche du prix sur tabPrix pour obtenir le n° d'ordre du prix pour la ref.

[fred1599]

Votre seconde solution est bien meilleure, mais on va détailler...

Vous exécutez un SELECT DISTINCT Ref, Prix... sur 1 million de lignes. Vous bouclez sur ce résultat (disons 700 000 paires uniques) pour construire en mémoire un tableau associatif (taRefPrix) potentiellement volumineux (50 000 clés pointant vers 50 000 sous-tableaux).

Vous devez ensuite (re)boucler sur les 1 million d'articles (POUR TOUT Articles...) pour utiliser ce tableau associatif (nRang = TableauRecherche(taRefPrix, Prix)), puis effectuer le HModifie.

Cela nécessite de stocker deux structures massives en mémoire :

1. Le taRefPrix (les 50 000 tableaux de consultation).
2. Le tabMisesAJour (le tableau de 1 million de structures {ID, Rang} à écrire).

Ai-je bien compris votre solution ?

[Voroltinquo]

Vous devez ensuite (re)boucler sur les 1 million d'articles (POUR TOUT Articles...) pour utiliser ce tableau associatif (nRang = TableauRecherche(taRefPrix, Prix)), puis effectuer le HModifie.
...
Le tabMisesAJour (le tableau de 1 million de structures {ID, Rang} à écrire).

D'où boucler sur le résultat ? La requête ne prend en compte que Ref et Prix. La recherche se fait pour chaque affichage de ligne, quelle que soit la méthode initiale de remplissage. Cette méthode initiale ne change pas.
Quel HModifie ?
Quel tabMiseAJour ?

En effet le tableau peut être volumineux, mais j'ai bien précisé que c'était la méthode bourrin. Si tu as plus simplle ...

[fred1599]

Mon analyse détaillée se basait sur un quiproquo : je pensais que vous vouliez modifier physiquement les données (un "batch" de HModifie ), alors que vous décrivez un calcul à la volée pour un affichage (dans l'événement TableAffiche, par exemple).

Dans ce contexte précis d'interface utilisateur (tableau associatif "Look-up") est robuste. Son avantage est qu'elle gère le tri par l'utilisateur. Si l'utilisateur clique sur un en-tête, votre logique de recherche (TableauRecherche) reste correcte.

Bien joué !

[Voroltinquo]

Avec ROW_NUMBER, on aurait pu se contenter d'une réquête puis FichierVersTableau, mais SQL 92 ne gère pas cette fonction. On n'a pas d'autre choix que de boucler pour remplir le tableau.
Je résume donc

Code txt :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
taRefPrix : tableau associatif de tableau de monétaire
tabPrix : tableau de monétaire
REQ_TriRefPrix : Requête REM uniquement Ref et Prix
TABLE_Article : champ qui récapitule les article
nRang: entir
 
Trier les articles par Ref et par Prix -> REQ_TriRefPrix
 
Lire REQ_TriRefPrix
TQ EnregistrementExiste
     Remplir taRefPrix REM REQ_TriRefPrix est triée par ref et par prix donc si on change de Ref, on attaque un nouveau tableau de prix
FTQ
 
Afficher TABLE_Article
POUR CHAQUE Affichage de ligne
     tabPrix:=taRefPrix[Ref]
     nRang:=Chercher Prix dans tabPrix
     Afficher nRang
FPOUR

[serendib]

https://doc.pcsoft.fr/fr-FR/?3044178

[fouedusa]

Bonjour,

La Requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
SELECT 
	Article.CodeArticle AS CodeArticle,	
	Article.LibelleArticle AS LibelleArticle,	
	Article.PrixArticle AS PrixArticle,	
	Article.OrdreArticle AS OrdreArticle
FROM 
	Article
ORDER BY 
	CodeArticle ASC,	
	PrixArticle ASC

Code du bouton :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
MonOrdreArticle est un entier = 0
MonCodeArticle est une chaîne = ""
LePrixArticle est un monétaire = 0.00
 
SI HExécuteRequête(REQ_MAJ_OrdreArticle, hModifieFichier) ALORS
	SI HLitPremier(REQ_MAJ_OrdreArticle) ALORS
		MonOrdreArticle = 1
		MonCodeArticle 	= REQ_MAJ_OrdreArticle.CodeArticle
		LePrixArticle 	= REQ_MAJ_OrdreArticle.PrixArticle
		TANTQUE HEnDehors(REQ_MAJ_OrdreArticle) = Faux
			SI REQ_MAJ_OrdreArticle.CodeArticle = MonCodeArticle ALORS
				SI REQ_MAJ_OrdreArticle.PrixArticle <> LePrixArticle ALORS
					MonOrdreArticle++
					MonCodeArticle 	= REQ_MAJ_OrdreArticle.CodeArticle
					LePrixArticle 	= REQ_MAJ_OrdreArticle.PrixArticle
				FIN
			SINON
				MonOrdreArticle = 1
				MonCodeArticle 	= REQ_MAJ_OrdreArticle.CodeArticle
				LePrixArticle 	= REQ_MAJ_OrdreArticle.PrixArticle
			FIN
 
			REQ_MAJ_OrdreArticle.OrdreArticle = MonOrdreArticle
			HModifie(REQ_MAJ_OrdreArticle)
 
			HLitSuivant(REQ_MAJ_OrdreArticle)
		FIN
	FIN
FIN
 
Info("Fin Traitement")

Bon Dev.

[Voroltinquo]

Encore faut il qu'il y ait une colonne OrdreArticle dans la table, ce n'est précisé nulle part.

Code du bouton :.

Quel bouton ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MonOrdreArticle est un entier = 0
MonCodeArticle est une chaîne = ""
LePrixArticle est un monétaire = 0.00

L'initialisation à 0 se fait lors de la déclaration, inutile da la refaire

SI HExécuteRequête(REQ_MAJ_OrdreArticle, hModifieFichier) ALORS

Sinon ?

SI HLitPremier(REQ_MAJ_OrdreArticle) ALORS

Sinon ?

[frenchsting]

Bonjour,

1. C'est marrant l'analyse que vous faites. Car vu ce que vous avez écrit, je suis certain que la personne qui a formulé la demande initiale n'en comprend pas la moitié ou au mieux est incapable de la coder.
2. Pour la requête, j'espère qu'il y a au moins une table des tarifs...

[JeAn-PhI]

Bonjour,

1 - La 1ère question est qu'elle est la base de données que vous utilisez ?
2 -

Je veux une requête ou code source sous Windev qui permet de mettre à jour la colonne ordreArticle de cette façon

ce n'est pas en exigent que vous aurez plus de réponse !!!!

[serendib]

Bonsoir,

Et dès qu'un prix change, on relance ?
Un peu alambiqué son truc à Spinx !

Une clef composée et hop.
(pas besoin de modifier l'article)

Mais je n'ai peut-être pas compris la problématique.

Bon, de toute façon, il a lâché l'affaire.

[Voroltinquo]

La clé composée va nous trouver les paires Ref/Prix, mais pas l'ordre du Prix pour une référence, à moins de faire un tri, et ce pour une ligne.
La modification de l'article est en effet inutile, qui plus est dans une colonne calculée, qui n'a rien à faire dans une table (persistance des données.)
Une solution intermédiaire si l'on veut conserver la colonne calculée serait
1-Modifier les données présentes, une fois pour toute. En supposant que ces données existent déjà chez le client et que tu ne commette pas l'erreur de remplir ta base finale en même temps que tu la conçoit.
2-Créer un trigger en Ajout/Supression qui recalcule l'ordre pour une référence donnée (on gagne le temps de création du tableau associatif)