Discussion :

[kir4000]

Bonjour,

Je me pose une question sur un univers.
En terme de performance de requêtage, faut-il plutôt passer par une vue de base rapatriée dans l'univers, ou passer par une table dérivée (même script que la vue) dans l'univers ?
Le script est lourd (une dizaine de tables jointes), presque tous les champs de la vue/table dérivée sont sources des objets.

[NorocBzh]

Je crois qu'il est mieux de faire une vue que l'on rapatrie ensuite dans l'univers.
Les tables dérivées sont assez consommatrices il me semble.

Si des personnes peuvent confirmer voir expliquer, je suis preneur

[djam21]

Hello,

A de rares exceptions près (notamment sur Terradata), la vue est plus performante que la table dérivée.

Quand tu fais une requête sur ta table dérivée, tu as en quelque sorte le code de création de ta vue.

Exemple (table dérivée) :

Code :

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

Select A, B from tableA tableB where TableA.id = tableB.id

Ce select sera executé à chaque fois que le rapport en question sera rafraichi. Donc plus il est complexe, plus ton rapport sera long à se rafraichir.

Pour une vue, ce code est généré une fois lors de la création et ne concerne pas BO.

Dans BO, le code associé sera :

Code :

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

Select A, B from Vue

BO n'aura pas à lier les tables permettant de créer la vue à chaque fois. Et verra la vue comme une table quelconque.

La perfomance se joue principalement à ce niveau-là entre les 2.

A+

[kir4000]

Merci pour ces réponses logiques.

Pour préciser, j'ai 3 tables dérivées, chacune multijointures (4 à 10).

En même temps, si je passe par une vue, le select sera également réexécuté en base à chaque rafraichissement de rapport.

Si certains ont des idées sur ce sujet sinon...http://www.developpez.net/forums/d12...ers-sqlserver/
C'est pour contourner le problème du sujet que je passe par des vues permettant de bien appréhender les jointures complexes.

Bonne journée!

[djam21]

Hello,

Si tu passes par une vue, elle ne sera pas rafraichit automatiquement au rafraichissement de ton rapport...

A+

[kir4000]

Merci djam21.

L'infocentre est alimenté toutes les semaines, donc les tables utilisées par les vues évoluent chaque semaine. Si au rafraichissement du rapport a semaine S+2, la vue n'est pas rafraichie, on perd alors les données de S+1 et S+2 ? Ce n'est pas une vue matérialisée. Ou alors faut-il planifiée la vue toutes les semaines ?

Pour le moment les tables dérivées de BO ne sont pas gourmandes en perf, je reste sur cette solution pour l'instant.

[Darksnakes]

Hello,

A de rares exceptions près (notamment sur Terradata), la vue est plus performante que la table dérivée.

Quand tu fais une requête sur ta table dérivée, tu as en quelque sorte le code de création de ta vue.

Exemple (table dérivée) :

Code :

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

Select A, B from tableA tableB where TableA.id = tableB.id

Ce select sera executé à chaque fois que le rapport en question sera rafraichi. Donc plus il est complexe, plus ton rapport sera long à se rafraichir.

Pour une vue, ce code est généré une fois lors de la création et ne concerne pas BO.

Dans BO, le code associé sera :

Code :

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

Select A, B from Vue

BO n'aura pas à lier les tables permettant de créer la vue à chaque fois. Et verra la vue comme une table quelconque.

La perfomance se joue principalement à ce niveau-là entre les 2.

A+

Dans le cas de la vue, la jointure sera faite également. Elle est juste cachée dans le code généré .... La seule différence est que la vue est accessible dans la base (débug, consultation, réutilisation) alors que la table dérivée non. Les tables dérivées sont faites pour les développeurs qui n'ont pas accès à la base de données