Sans risque ?

Bonjour,

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

Code:

---

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:

---

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.

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

Citation:

---

Envoyé par StringBuilder

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

Citation:

---

Envoyé par mnitu

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.

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.

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 :

Citation:

---

Envoyé par Oracle

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.

---

Citation:

---

Envoyé par 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

---

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

Salut,

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

Code:

---

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 :aie:

Citation:

---

Envoyé par pacmann

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.

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 :)

Bonnes remarques à propos des "null" et de la "fausse fk".

L'ERP en question ne supporte pas les NULL (sinon ça plante).
Donc les deux requêtes sont équivalentent, car la première ne peut retourner aucun NULL dans col5 et col6.

De la même façon, le NOT EXISTS est nécessaire puisque lorsqu'il n'y a pas d'enregistrement dans table3, alors table1.fk_table3 est égal à ' ' (un espace) qui est une valeur interdite dans table3.id.
Cela dit, on pourrait faire un where table1.fk_table3 = ' ', mais vu que la FK n'est pas matérialisée dans la base, rien ne nous garanti que la valeur 'TOTO' qui se trouve dans "table1.fk_table3" est une valeur présente dans "table3.id"

L'ERP date des premières version de SGBD, dans lesquels les notions de clé étrangère n'existaient pas. Les choix techniques au niveau du modèle des données pris par la suite on tout simplement rendus impossible l'ajout de telles contraintes par la suite.

En 11gR2 le parser Oracle est capable de faire des transformations de type 'null aware anti join', du coup avant de se plonger dans une réécriture de la requête il peut-être intéressant de voire comment elle est réécrite et donc de faire un explain plan sur le "select" correspondant en trace 10053. Non ?

Citation:

---

Envoyé par Rei Ichido

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/

Pour ma part je pense que c'est une bonne amélioration.
À tester bien entendu avant tout déploiement.

Citation:

---

Envoyé par StringBuilder

L'ERP date des premières version de SGBD

---

/*+RULE*/ hint donc :)