Discussion :

[awalter1]

Bonjour,

J'ai une table défini comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE ENV
(POINT_NAME VARCHAR2(5) NOT NULL,
INDEX_NUMBER INTEGER NOT NULL,
COORD INTEGER NOT NULL)
;
CREATE UNIQUE INDEX ENV_I1
ON ENV
(POINT_NAME ASC,
INDEX_NUMBER ASC)
;

Le champ INDEX représente un numéro qui s'incrémente de 10 en 10. Il arrive que suite à des suppressions de record, il y ait des trous dans la numérotation. Je voudrais alors une requète UPDATE pour renuméroter tous les records pour retrouver une séquence ordonnée 10, 20, 30 ... là ou j'avais peut être 20,50,60 ... Je n'arrive pas à le faire en une requète SQL.
Je travaille en Oracle 10i.
Merci de votre aide

[Magnus]

Je voudrais alors une requète UPDATE pour renuméroter tous les records pour retrouver une séquence ordonnée 10, 20, 30 ... là ou j'avais peut être 20,50,60 ... Je n'arrive pas à le faire en une requète SQL.

Et si vous devez restaurer une partie d'une sauvegarde ou simplement restaurer un enregistrement, etc. vous allez avoir une violation de vos contraintes d'intégrité.
Les trous occasionés par les séquences ne doivent JAMAIS être comblés et TOUJOURS être considérés commer perdus.

A bon entendeur.

[awalter1]

merci d'avoir répondu.
Mais mon champ INDEX_NUMBER n'est pas une séquence (au sens Oracle). j' ai utilisé le terme séquence à mauvais escient, il fallait comprendre suite croissante car ce champ sert à conserver l'ordre choisi par l'utilisateur lors de ces actions d'insertion, update, suppression.

[plaineR]

Il ne fait pas partie de la clé d'unicité de la table ?

[awalter1]

On ne gère pas de clé, ou plutot c'est fait au moyen de l'unicité des index. Mon champ INDEX_NUMBER fait partie de cet index. c'est là que c'est embêtant car on ne peut pas numérotez en partant de 10 et en ajoutant 10 et ainsi de suite car on va tomber probablement sur un index déjà existant et donc pb d'unicité. Pour bien faire il faudrait trouver les trous et renuméroter les records suivants à partir de là : update ENV set INDEX_NUMBER =INDEX_NUMBER +10 where INDEX_NUMBER >= ??? ... Mais pour trouver les trous et relier le tout, je sèche.
merci

[phili_b]

il faudrait partir du nombre max de lignes*10 et soustraire de 10 en 10.

[SQLpro]

Il faut utiliser une inéqui auto jointure avec comptage dans une sous requête de l'UPDATE.
Démo :

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
CREATE TABLE T10 (T10_ID     INT NOT NULL PRIMARY KEY,
                  T10_NUM    INT)
 
INSERT INTO T10 VALUES (4, 20)
INSERT INTO T10 VALUES (12, 140)
INSERT INTO T10 VALUES (18, 60)
 
UPDATE T10
SET    T10_NUM = (SELECT N
                  FROM (SELECT T1.T10_ID AS I, COUNT(*) * 10 AS N
                        FROM   T10 T1
                               INNER JOIN T10 T2
                                     ON T1.T10_ID >= T2.T10_ID
                        GROUP  BY T1.T10_ID) T
                  WHERE I = T10.T10_ID)
 
SELECT * 
FROM   T10
 
T10_ID      T10_NUM     
----------- ----------- 
4           10
12          20
18          30

A +

[phili_b]

>sqlpro
J'y étais presque hier soir, ça y ressemblait beaucoup, mais le group by ne fonctionnait pas. J'ai essayé ta requête, ça marche nickel.

>awalter1
Cette algo, expliqué par Sqlpro, peut servir aux SGBDR ne supportant pas le rownum et/ou le row_number(), comme les vieilles versions de SQL server. Il faut regarder en particulier sa partie SELECT si on veut comprendre ce que fait l'algo, c'est typiquement une FAQ SQL qu'on a pourtant du mal à retrouver:

Code :

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

1
2
3
4
5
SELECT T1.T10_ID AS I, COUNT(*) * 10 AS N
FROM   T10 T1
    INNER JOIN T10 T2
         ON T1.T10_ID >= T2.T10_ID
GROUP  BY T1.T10_ID

[awalter1]

merci de votre contribution.