[Oracle 7.3.4/SQL] Problème de sélection de première ligne de résultat(s) avec ROWNUM

Version imprimable

Voir 40 message(s) de cette discussion en une page

Citation:

Envoyé par remi4444

eh bien moi j'en suis pas si sur...

Je te confirme ce que dis Fred, cela ne fait aucun doute. Le rownum dépend du niveau ou tu es. ;)
Pour preuve :

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
SQL> select table_name, rownum, rnum
  2  from (select table_name, rownum rnum
  3        from all_tables
  4        where owner = 'SYS'
  5           and table_name like 'A%'
  6        order by table_name desc);
 
TABLE_NAME                        ROWNUM      RNUM
------------------------------ --------- ---------
AUDIT_ACTIONS                          1        15
AUDIT$                                 2        14
AUD$                                   3        13
ATTRIBUTE$                             4        12
ATTRCOL$                               5        11
ATEMPTAB$                              6        10
ASSOCIATION$                           7         9
ARGUMENT$                              8         8
AQ$_SCHEDULES                          9         7
AQ$_QUEUE_TABLE_AFFINITIES            10         6
AQ$_QUEUE_STATISTICS                  11         5
AQ$_PROPAGATION_STATUS                12         4
AQ$_PENDING_MESSAGES                  13         3
AQ$_MESSAGE_TYPES                     14         2
ACCESS$                               15         1
 
15 rows selected.

18/08/2006, 12h07
orafrance

Citation:

Envoyé par remi4444

si je l'ai bien saisi, utiliser le max s'avère plus simple et surtout plus juste d'un point de vue fonctionnel. Le rownum c'est du technique, c'est pas tout à fait la même chose.

sauf que le MAX génère du tri que tu évites avec ROWNUM ;)
18/08/2006, 12h07
plaineR

Citation:

Envoyé par remi4444

si si, en partie du moins... ;)

imagine par exemple que tu ais dans ta table 50 fois le meme employee_id à 0 avec des données diverses dans les autres colonnes.

Selon la base de donnée, l'ordre d'insertion etc... les 11 lignes ramenées ne seront pas les mêmes...

Oui, mais pour une même base de données, l'ordre sera toujours le même
=> ce n'est pas aléatoire, c'est toi qui ne vois pas le critère de tri (s'il n'y a pas d'index de pris en compte, il me semble que c'est en fonction du rowid)

j'admet que j'ai peut etre été un peu caricatural... effectivement il faut bien faire attention au parenthèses, c'est la qu'est le danger à mon avis

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
 
select table_name
    from all_tables
where owner = 'SYS'
    and table_name like 'A%'
	and rownum <= 5
order by table_name desc
 
TABLE_NAME                    
------------------------------
APPLY$_DEST_OBJ_OPS           
APPLY$_DEST_OBJ_CMAP          
APPLY$_DEST_OBJ               
APPLY$_CONF_HDLR_COLUMNS      
ACCESS$                       
 
5 rows selected
 
--...........................................................................
 
select * from (
  select table_name
          from all_tables
        where owner = 'SYS'
          and table_name like 'A%'
        order by table_name desc
	    )
where rownum <= 5
 
TABLE_NAME                    
------------------------------
AW$                           
AUX_STATS$                    
AUDIT_ACTIONS                 
AUDIT$                        
AUD$                          
 
5 rows selected

Là l'erreur est facile à voir mais quand vous avez une requête complexe avec des rownum partout... :aie:

18/08/2006, 12h23
remi4444

Citation:

Envoyé par plaineR

Oui, mais pour une même base de données, l'ordre sera toujours le même
=> ce n'est pas aléatoire, c'est toi qui ne vois pas le critère de tri (s'il n'y a pas d'index de pris en compte, il me semble que c'est en fonction du rowid)

quand je dis "aléatoire" je me met du coté fonctionnel, j'imagine par exemple le passage en prod d'une application qui à été "validée" en intégration...
18/08/2006, 12h24
orafrance

Citation:

Envoyé par remi4444

Là l'erreur est facile à voir mais quand vous avez une requête complexe avec des rownum partout... :aie:

de toute façon... ROWNUM c'est has-been... vive le RANK 8-) :mrgreen:
18/08/2006, 12h25
remi4444

Citation:

Envoyé par Fred_D

sauf que le MAX génère du tri que tu évites avec ROWNUM ;)

et le "ORDER BY" c'est du poulet ? :mouarf:
18/08/2006, 12h35
orafrance

là en l'occurence il n'y a pas de ORDER BY puisqu'il en veut un... quelqu'il soit a priori non ? ;)
18/08/2006, 14h11
remi4444

ben non.... il ne veut pas n'importe lequel justement sinon il se serait pas fatigué à mettre un "ORDER BY" dans sa sous-requête.

On s'emporte on s'emporte et on oublie le problème initial ;)
18/08/2006, 14h15
orafrance

sauf que la condition t1.t1_version=tv.tv_version ne permet d'avoir qu'une seule valeur de version... le MAX ne sert qu'à ne prendre qu'une seule ligne... ou alors il y a un problème dans la requête :ange:
18/08/2006, 14h23
laurentschneider

Citation:

Envoyé par remi4444

si si, en partie du moins... ;)

imagine par exemple que tu ais dans ta table 50 fois le meme employee_id à 0 avec des données diverses dans les autres colonnes.

Selon la base de donnée, l'ordre d'insertion etc... les 11 lignes ramenées ne seront pas les mêmes...

tout à fait d'accord, si tu as 50 employés avec le même employee_id, et que tu fais order by employee_id, tu n'as aucune idée de ce que tu recevras.

Cependant, si employee_id est une clé primaire, alors rownum n'est plus du tout aléatoire.

OK?
18/08/2006, 14h24
laurentschneider

il est bien sûr inconcevable d'avoir 50 employés avec le même numéro d'employé, mais je dis ça parce que l'on est vendredi 8-)
18/08/2006, 14h38
remi4444

Citation:

Envoyé par Fred_D

sauf que la condition t1.t1_version=tv.tv_version ne permet d'avoir qu'une seule valeur de version... le MAX ne sert qu'à ne prendre qu'une seule ligne... ou alors il y a un problème dans la requête :ange:

ben... tout vient du fait qu'il est impossible de faire un ORDER BY dans une sous-requête en oracle-7. Donc si ça sert à rien dans la requête, je vois pas pourquoi on s'en..... autan faire un "ROWNUM = 1" dans le dernier niveau et clic/clac l'affaire est dans le sac... 8-)
18/08/2006, 14h47
remi4444

Citation:

Envoyé par laurentschneider

Cependant, si employee_id est une clé primaire, alors rownum n'est plus du tout aléatoire.

OK?

Effectivement ça devient vrai en n'oubliant pas de poser l'hypothèse de départ qu'il y a une clause d'unicité sur la colonne de tri.

Mais même dans l'exemple d'Oracle que tu cite, c'est bien pour un problème de reporting (donc d'affichage) qu'est utilisé le rownum, pas pour la récupération d'un max. C'est pour ça que, quand je veux récupérer un maximum, personnellement je préfère utiliser la fonction MAX :roll:
18/08/2006, 14h48
orafrance

Citation:

Envoyé par remi4444

ben... tout vient du fait qu'il est impossible de faire un ORDER BY dans une sous-requête en oracle-7. Donc si ça sert à rien dans la requête, je vois pas pourquoi on s'en..... autan faire un "ROWNUM = 1" dans le dernier niveau et clic/clac l'affaire est dans le sac... 8-)

c'est bien ça :mrgreen:

Voir 40 message(s) de cette discussion en une page