
Envoyé par
SQLpro
C'est bien pire avec oracle qui impose la table DUAL pour éviter de recourir à un SELECT sans FROM.
Insert into sys.dual values ('Y');
Et voilà comment tuer une application (en même temps si on vous a filer SYS ou SYSTEM il y a un trou de sécurité plus important à combler).
Bon depuis je ne sais plus quelle version les appels à dual sont "virtuels", la base sait qu'il n'y a rien à faire tant qu'on ne requête pas spécifiquement la colonne DUMMY.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
| explain plan for select sysdate from dual;
-----------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------
explain plan for select sysdate, dummy from dual;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |
-------------------------------------------------------------------------- |
En vrai ce n'est pas très grave on s'habitue très vite à l'une ou l'autre syntaxe.

Envoyé par
SQLpro
Parlons du ROWID, du ROWNUM et de toutes les pseudo colonne des tables...
Rownum est une pseudo-colonne évaluée à la requête, ça ne me paraît pas dramatique et c'était nécessaire pour faire de la pagination avant l'introduction des fonctions de fenêtrages à la fin des années 90.
Pour le RowId il existe aussi dans SQL-Server sur les tables nonclustered, il n'est simplement pas requêtable (enfin je ne crois pas).
Partager