Discussion :

[plaineR]

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 :

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
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.

[orafrance]

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

[plaineR]

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)

[remi4444]

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 :

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
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...

[remi4444]

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...

[orafrance]

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

de toute façon... ROWNUM c'est has-been... vive le RANK

[remi4444]

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

et le "ORDER BY" c'est du poulet ?

[orafrance]

là en l'occurence il n'y a pas de ORDER BY puisqu'il en veut un... quelqu'il soit a priori non ?

[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

[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

[laurentschneider]

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?

[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

[remi4444]

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

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...

[remi4444]

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

[orafrance]

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...

c'est bien ça