Discussion :

[nuke_y]

Bonjour,

une petite question :

comme je travaille avec des outils qui génèrent leurs propre code SQL et que certaines requêtes sont trop compliquées pour qu'ils comprennent comment les faire, je veux passer par des vues qui contiendraient la requête compliquée et sur laquelle l'outil n'aurait plus qu'à faire une requête de sélection simple.

Le problème c'est que tout le monde (dans mon entourage professionnel) me dit que je vais "flinguer les perfs avec des vues car les vues n'utilisent pas les index". Alors moi je dis certes, mais sinon ? Parce que leur méthode à eux c'est de tout copier dans une table supplémentaire sur laquelle on viendra requêter... Et au niveau performances franchement je vois pas trop en quoi mes vues le sont moins que leurs requêtes.

Alors j'aimerais votre avis sur le sujet, si il est VRAIMENT reconnu que les vues flinguent les perfs, s'il y a un moyen de contourner le problème, etc.

Merci

[Jaouad]

flinguer les perfs avec des vues car les vues n'utilisent pas les index".

Salut Nuke , v²oila encore une idéé pré concue sous Oracle qui à la dent longue .
Une vue n'est qu'une requête qui est stocké dans le dictionniare des données .Donc elle prend moins de place que de stocké directement toutes les données en doubles .

De plus si ta table est indexée et que dans la définition de la vue ou dans l'appel de celle ci on a des conditions satisfaisantes pour l'index il est appellé :

CREATE VIEW ps_personal_data_vw AS SELECT * FROM ps_personal_data ;

SQL> ---- requête sur la table
SQL> SELECT * FROM ps_personal_data
2 WHERE emplid =021131
3 AND name LIKE 'ZOUAGH%' ;


Plan d'exécution
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=9 Card=3 Bytes=1050)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'PS_PERSONAL_DATA' (Cost=
9 Card=3 Bytes=1050)

2 1 INDEX (RANGE SCAN) OF 'PS0PERSONAL_DATA' (NON-UNIQUE) (C
ost=5 Card=3)



SQL> --- sur la vue
SQL> SELECT * FROM ps_personal_data_vw
2 WHERE emplid =021131
3 AND name LIKE 'ZOUAGH%' ;


Plan d'exécution
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=9 Card=3 Bytes=1050)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'PS_PERSONAL_DATA' (Cost=
9 Card=3 Bytes=1050)

2 1 INDEX (RANGE SCAN) OF 'PS0PERSONAL_DATA' (NON-UNIQUE) (C
ost=5 Card=3)

[nuke_y]

Ah ben voila exactement le genre de réponse que j'attendais !! Je me disais aussi qu'elles étaient bien rapides mes requêtes sans Index !!

Pffff, mon dieu que les gens sont cons... heureusement qu'il y en a pour demander à ceux qui savent ( et qu'il y en a qui savent pour répondre).

Bon ben je vais faire comme ça.

Et euh au fait, ça peut me faire des circonstances atténuantes ce que tu as dit, si je tue le prochain qui me sort ce genre d'a-priori ?

En tous cas, merci beaucoup !!

[Jaouad]

Le juge de paix dans ce cas là est l'explain plan :
Sous sql*plus

Code :

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

1
2
 
set autotrace trace

Attention quand même car il exécute la requête ( insert , update , delete , select .... )

Sinon tu peux faire :

Code :

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

1
2
 
set explain plan for requête

[Jaouad]

Et euh au fait, ça peut me faire des circonstances atténuantes ce que tu as dit, si je tue le prochain qui me sort ce genre d'a-priori ?

En tous cas, merci beaucoup !!

Le tuer , non c'est trop mais peut être qu'un rappel à l'ordre

[orafrance]

Le problème c'est que tout le monde (dans mon entourage professionnel) me dit que je vais "flinguer les perfs avec des vues car les vues n'utilisent pas les index".

S'en serait risible si ce n'était pas si triste de voir des choses pareilles

Maintenant tu sais qui aller voir si tu n'as besoin de rien