Discussion :

[tanaka59]

Bonjour,

Je dispose d'une table relativement simple à trois colonnes . On va supposé qu'elle est déjà triée.

Champ A = une clef primaire > champ texte
Champ B = une chaine contenant des codes gestions > varchar de 2 caractères
Champ C = une quantité > suite à un comptage par exemple

Pour l'exemple on supposera des numéros de téléphone ayant fait des communications dans un certains nombre de pays, le tout classé par téléphone et top/limit du nombre de communication .

Code csv :

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
2461234567;es;15;1
2461234567;cn;12;2
2461234567;kz;12;3
2461234567;es;7;4
2461234567;kz;3;1
2681234567;ch;23;2
2681234567;be;18;3
2681234567;jp;9;1
3401234567;mm;24;2
3401234567;ph;19;1
4411234567;ve;21;2
4411234567;kz;16;3
4411234567;pl;13;4
4411234567;jp;1;1
7841234567;jp;25;2
7841234567;ir;23;3
7841234567;eg;22;4
7841234567;pe;22;5
7841234567;pk;21;6
7841234567;th;20;7
7841234567;kz;20;8
7841234567;ca;18;9
7841234567;ca;13;10
7841234567;ao;9;11
7841234567;kz;7;12
7841234567;th;6;13
7841234567;kr;5;14
7841234567;al;5;15

Comme sur l'exemple en CSV je souhaite venir mettre un compteur qui revient à un à chaque nouveau numéro de téléphone . Si "téléphone" de la ligne = "téléphone" de la ligne +1 alors compteur +1 sinon revenir à 1 et recommencer la boucle.

Est il possible de faire cela en SQL pure (genre MySQL ou Oracle) ?

Merci de m'aiguiller

[ectap]

Bonjour

Tu peut utiliser la fonction ROW_NUMBER()

Par contre le SQL de certains SGBDR ne permet pas d'utiliser ROW_NUMBER() dans un update
--> dans ce cas il faut faire une sous requete ou une CTE cf https://stackoverflow.com/questions/...lause/19124799

Bonne Soirée

[tanaka59]

Bonjour

Dans mon cas la requete avec le row_number pour classer :

Code sql :

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

1
2
select tel, pays, qte , chn_faq , ROW_NUMBER() over(partition by tel order by qte desc) , chn_trsp
from matable;

[Waldar]

Code csv :

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

1
2
3
4
5
6
7
8
9
2461234567;es;15;1
2461234567;cn;12;2
2461234567;kz;3;1
2681234567;ch;23;2
3401234567;mm;24;2
3401234567;ph;19;1
4411234567;ve;21;2
4411234567;jp;1;1
7841234567;jp;25;2

Comme sur l'exemple en CSV je souhaite venir mettre un compteur qui revient à un à chaque nouveau numéro de téléphone.
Si "téléphone" de la ligne = "téléphone" de la ligne +1 alors compteur +1 sinon revenir à 1 et recommencer la boucle.

C'est bizarre comme algorithme.
Du coup votre premier numéro de téléphone se retrouve avec deux fois le compteur 1, et le dernier sans jamais compteur 1.
J'ai réduit vos données dans la citation pour que ce soit plus visible.

En général l'algorithme c'est plutôt :
Si "téléphone" de la ligne = "téléphone" de la ligne -1 alors compteur +1 sinon revenir à 1 et recommencer la boucle.

C'est ce que font les fonctions analytiques, elles repartent à 1 lors d'une nouvelle entrée.

[SQLpro]

Bonjour,

Je dispose d'une table relativement simple à trois colonnes . On va supposé qu'elle est déjà triée.

Supposition fausse, par nature une table n'a pas d'ordre naturel des données. tantôt le SGBDR vous les restituera dans un sens, tantôt dans l'autre....

A lire : https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L5

A +

[tanaka59]

Bonjour,

Supposition fausse, par nature une table n'a pas d'ordre naturel des données. tantôt le SGBDR vous les restituera dans un sens, tantôt dans l'autre....

A lire : https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L5

A +

Dans le cas présent il y a un ordre de classement artificiel qui est imposé pour générer un compteur . On va se servir de l'ordre de classification sinon impossible de faire la requête ...

[SQLpro]

Bonjour,



Dans le cas présent il y a un ordre de classement artificiel qui est imposé pour générer un compteur . On va se servir de l'ordre de classification sinon impossible de faire la requête ...

mais tôt ou tard, ca pétera... pas exemple sir la requête est traitée en parallèle !

A +

[SQLpro]

Une table n'est pas une feuille excel et les lignes des tables sont disposées au hasard sans aucun ordre logique. Le simple fait de supposer qu'il existe un ordre contrevient à la théorie des ensembles. Or par nature les éléments des tables (lignes) sont des ensembles que le SGBDR peut changer de place à tout moment sans vous prévenir ! Autrefois les lignes étaient stockées dans des fichiers dans un certain ordre. Mais heureusement dans les SGBDR ce n'est jamais le cas...
Suivant les index que vous allez ajouter, suivant les suppressions et les ajouts, suivant la maintenance que vous allez faire dans votre base... ces lignes vont bouger...
Le pire étant le parallélisme qui fait que l'ordre de prise en compte des lignes, et donc l'odre de restitution des résultats peut varier systématiquement lorsque l'on relance la requête.

Exemple (sous MS SQL Server 2017) :

Avec la table suivant :

Code :

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

1
2
3
4
5
-- création d'une table 
CREATE TABLE T_BIG
(BIG_GUID        UNIQUEIDENTIFIER NOT NULL PRIMARY KEY DEFAULT NEWID(),
 BIG_DATA        CHAR(2000));
GO

Dans laquelle on met les données suivantes :

Code :

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

1
2
3
4
5
6
7
8
9
10
-- insertion de 333 lignes
INSERT INTO T_BIG DEFAULT VALUES;
GO 333
 
-- insertion de 110 889 lignes supplémentaires
INSERT INTO T_BIG (BIG_DATA)
SELECT CAST(T1.BIG_GUID AS char(36)) + '.' +  CAST(T2.BIG_GUID AS char(36))
FROM   T_BIG AS T1
       CROSS JOIN T_BIG AS T2;
GO

L'exécution de la requête suivante ne donne jamais le même ordre des lignes, mais le résultat est identique !

Code :

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

1
2
3
4
-- la requête :
SELECT LEFT(BIG_GUID, 2), COUNT(*) 
FROM T_BIG                  
GROUP  BY LEFT(BIG_GUID, 2);

Ceci est expliqué par le fait que la requête est parallélisée :


C'est d'ailleurs pour cela qu'il existe une clause ORDER BY dans le langage SQL pour ordonner les lignes du RÉSULTAT !

A +