Discussion :

[StringBuilder]

Bonjour,

Je travaille sur un ERP qui livre en standard des vues de ce type :

Code sql :

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
 
create view mavue (
  col1, col2, col3, col4, col5, col6
)
as
select table1.col1, table1.col2, table2.col3, table2.col4, table3.col5, table3.col6
from table1, table2, table3
where table2.id = table1.fk_table2
and table3.id = table1.fk_table3
union all
select table1.col1, table1.col2, table2.col3, table2.col4, ' ', ' '
from table1, table2
where table2.id = table1.fk_table2
and not exists (
  select 1
  from table3
  where table3.id = table1.fk_table3
);

Vu que ça me fait froid dans le dos à chaque fois que je tombe dessus, et que je dois les dériver pour les personnaliser, je souhaite les réécrire de cette façon :

Code sql :

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

1
2
3
4
5
6
7
8
9
 
create view mavue (
  col1, col2, col3, col4, col5, col6
)
as
select table1.col1, table1.col2, table2.col3, table2.col4, coalesce(table3.col5, ' '), coalesce(table3.col6, ' ')
from table1
inner join table2 on table2.id = table1.fk_table2
left outer join table3 on table3.id = table1.fk_table3;

Est-ce que je risque quoi que ce soit :
- en terme de données (pour moi, les deux écritures sont strictement équivalentes en terme de résultat, mais je voudrais en être certain)
- en terme de performances (pour moi, la nouvelle syntaxe est plus rapide, mais comment en être sûr ?)

Ces vues tournent sous Oracle 11gR2.

[laurentschneider]

oui, tu risques d'avoir des résultats différents. Moi je laisserais la requête telle quelle !

et tu risques aussi d'avoir une moins bonne performance si ton ERP utilise des HINT qui s'adresse à la vue origininale

[amir.]

oui, tu risques d'avoir des résultats différents. Moi je laisserais la requête telle quelle !

et tu risques aussi d'avoir une moins bonne performance si ton ERP utilise des HINT qui s'adresse à la vue origininale

Ce serait quand même un peu idiot de coder des HINTs en dur dans un ERP non? Moi je trouve les HINTs utiles au niveau du développement et du tuning des requêtes mais une fois en production, les systèmes ne devraient pas contenir des hints. C'est comme si on disait à l'optimiseur "Ecoute, je sais mieux que toi ce que tu fais, je te force à le faire ainsi". Mais les données évoluent. Peut-être qu'un certains HINT pourrait être utile à un certain moment, mais les données évoluent et peut-etre que ce hint dégraderait les performances 15 jours plus tard. Les systèmes aussi évoluent...

[pacmann]

Salut,

En parlant de truc potentiellement idiot, on a quand même :

Code :

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

1
2
3
4
5
6
 
AND NOT EXISTS (
  SELECT 1
  FROM table3
  WHERE table3.id = table1.fk_table3
);

Je sais que je devrais pas interpréter hativement... mais ça donne quand même l'impression que la fk sur table3 peut ne pas être dans table3

Sinon sur les performances, on ne peut rien conclure. Il se pourrait même que cette requête soit une réécriture de celle proposée StringBuilder afin de résoudre un problème de perfs

[Rei Ichido]

Je sais que je devrais pas interpréter hativement... mais ça donne quand même l'impression que la fk sur table3 peut ne pas être dans table3

C'est vrai que s'il s'agit d'une vraie Foreign Key, on pourrait se dispenser de faire cet EXISTS et juste vérifier table1.fk_table3 IS NULL.

[laurentschneider]

la requete 1 pourrait retourner des valeurs nulles de table3.col5, alors que la requete 2 ne retournera pas de nul

ensuite, il n'y a rien d'idiot a employer des hints. Les gros ERP, style SAP, Siebel, Peoplesoft, ont optimiser a leur facon les requetes et les reecrire n'est generalement pas supporte.

Contacte ton fournisseur ERP et propose-lui ton amelioration

[mnitu]

...
- en terme de performances (pour moi, la nouvelle syntaxe est plus rapide, mais comment en être sûr ?)

Chez Oracle c’est un mythe. Mais juste par curiosité, dite moi que est-ce que vous faite pensez que la syntaxe ANSI pouvait être plus rapide ?

Oui je trouve aussi les deux écritures équivalentes.

[Rei Ichido]

Chez Oracle c’est un mythe. Mais juste par curiosité, dite moi que est-ce que vous faite pensez que la syntaxe ANSI pouvait être plus rapide ?

Il ne s'agit pas ici de dire que la syntaxe ANSI est plus rapide, mais de dire que procéder à une requête sur les tables T1, T2 et T3, puis (avec union all) à une requête sur T1 et T2 dans le cas où il n'y aurait pas de correspondance avec T3, semble être plus lent que faire directement une requête sur T1, T2 et T3 en ouvert - les tables vont être accédées 2 fois au lieu d'une seule.

[StringBuilder]

Oui c'est ça Rei Ichido, le UNION me pose un sérieux problème, ce n'est pas seulement l'écriture des jointures qui me gêne.

[Rei Ichido]

Sur le papier, la requête a bien l'air équivalente. Cela dit, à l'instar de Laurent Schneider, le risque de régression me semble non négligeable, surtout si vous le faites sur beaucoup de vues (une erreur est vite arrivée).
En ce qui concerne le risque par rapport aux hints, là pour le coup j'y crois moyennement, d'une part parce que quand les requêtes sont mal écrites, les hints sont relativement rares (et pas forcément adaptés), d'autre part parce que en plus l'utilisation des hints avec des vues n'est pas aisée :

Using Hints Against Views

By default, hints do not propagate inside a complex view. For example, if you specify a hint in a query that selects against a complex view, then that hint is not honored, because it is not pushed inside the view.

Note:
If the view is a single-table, then the hint is not propagated.

Unless the hints are inside the base view, they might not be honored from a query against the view.

[ojo77]

En ce qui concerne le risque par rapport aux hints, là pour le coup j'y crois moyennement, [...] parce que en plus l'utilisation des hints avec des vues n'est pas aisée

Pas si compliquée quand même en 11g avec les Query Blocks :

http://jonathanlewis.wordpress.com/2007/06/25/qb_name/
http://blog.easyteam.fr/2012/10/11/o...nant-des-vues/