Discussion :

[Invité]

Bonjour à tous,

dans notre application, nous gérons différents types de personnes et d'adresses. L'extraction de certains types d'adresses étant compliqué, nous avons une table qui contient ces données. Ces données sont donc censées être gardées à jour en tout temps, à l'aide de triggers et de procédures lancées journalièrement. Bien entendu, c'est assez compliqué et bien entendu aussi, c'est un peu buggé. Et pour couronner le tout, le code date de 10 ans et est franchement indigeste !

Mon travail est donc de réécrire ce code. Mais j'aimerais aller plus loin. J'aimerais ne plus devoir passer par cette table "calculée". Elle est trop compliquée à maintenir à jour. J'ai donc créé des fonctions qui me retournent des record (record d'environ 15 champs). Pour du code PL/SQL, c'est le pied. Par contre, on a beaucoup de vues qui se basent sur cette table que j'aimerais supprimer.

Ma question : y'a-t-il une possibilité, dans une vue, d'utiliser le résultat d'une fonction qui est sous forme de record, sans appeler n fois la fonction ?
J'ai ajouté une fonction pour chaque champs de mon record, mais dans une vue qui a besoin de tous ces champs, la fonction est appelée 15 fois -> c'est lent...

Une idée ???

Merci !

[mnitu]

Le problème n’est pas que ta fonction est appelée 15 fois pour obtenir chaque valeur, mais que les 15 appels sont effectués autant de fois que des enregistrements ramènes.
Que est-ce que tu veux dire par extraction de ces adresses ? Si vraiment on ne peut pas les éviter il faut peut être étudier l’emploi des vue matérialisés.
Il n’est pas possible d’utiliser des ‘record’ dans un vue mais il est possible :

• d’utiliser des fonctions pipelined
• d’utiliser des objets

Mais je suis loin d’être convaincu que t’a vraiment besoin de ça.

[Invité]

Que est-ce que tu veux dire par extraction de ces adresses ?

Par extraction, j'entends la recherche de ces données adresses dans mon schéma. Ca touche 4-5 tables, et suivant les cas, il peut y avoir beaucoup de conditions -> pas possible avec une requête.

Si vraiment on ne peut pas les éviter il faut peut être étudier l’emploi des vue matérialisés.

J'en utilise déjà pour des données statistiques, mais mise à jour journalièrement. Dans ce cas, la mise à jour doit être immédiate. Je vais étudier la chose.

Il n’est pas possible d’utiliser des ‘record’ dans un vue mais il est possible :

• d’utiliser des fonctions pipelined
• d’utiliser des objets

Mais je suis loin d’être convaincu que t’a vraiment besoin de ça.

Je vais quand même y jeter un oeil.

Merci !

[Invité]

Après quelques recherches et essais :

- une vue matérialisée est basée sur une requête -> pas applicable dans mon cas

- une pipelined fonction marche bien, mais dès que je l'utilise dans un select avec un lien sur une autre table, l'exécution de cette dernière prend un temps fou -> pas utilisable

Je crois que je vais être obligé de remettre en place notre ancien méchanisme, qui se base sur des triggers sur les tables en causes et qui utilise le scheduler Oracle (dbms_job) pour chercher et mettre à jour les données dans cette table "dupliquée"...

Dommage...

[orafrance]

si la fonction retourne un REF CURSOR ça devrait régler le problème non ?

[mnitu]

si la fonction retourne un REF CURSOR ça devrait régler le problème non ?

Je ne pense pas, parce qu’il veut mettre tout ça dans une vue.
Par contre pour l’histoire de

…
- une pipelined fonction marche bien, mais dès que je l'utilise dans un select avec un lien sur une autre table, l'exécution de cette dernière prend un temps fou -> pas utilisable
…

il sera mieux d’avoir un exemple à la place d’une conclusion non soutenu par un jeux d’essai.

[mnitu]

...
- une pipelined fonction marche bien, mais dès que je l'utilise dans un select avec un lien sur une autre table, l'exécution de cette dernière prend un temps fou -> pas utilisable
...

Voila un exemple qui démontre plutôt le contraire.

[Invité]

Voila un exemple qui démontre plutôt le contraire.

Cet exemple est un peu léger avec sa table de 100 records. La même table avec 100000 records et il faut 95 s. pour récupérer la premier résultat !