Discussion :

[Simeans2004]

Bonjour,

je voulais savoir si il etait possible sous oracle 8i de faire une materialized
view (ou view simple) qui prendrait en compte des parametres fournit par
un formulaire web.

Ce serait pour faire des rapports entre differentes tables deja presentes.

merci d'avance pour le derangement.

John.

[argoet]

je ne pense pas que cela soit possible (en direct) .
par contre rien ne t'empeche de renseigner une table temporaire (TEMPORARY TABLE depuis la 8i ) avec tes parametres sur laquelle ta vue peut s'appuyer

[SheikYerbouti]

Avec les droits de création de vue et l'instruction execute immediate, vous pourriez effectivement construire une telle vue. (pensez toutefois à la suppression)

[Simeans2004]

Merci deja d'avoir repondu a ma question. Cependant, le fait de creer une autre table ou de faire une materialized view dynamique ne me faciliterai pas specialement la tache finalement.

En revanche, je me demandais juste si il etait possible de faire une materialized view sur une requete qui englobe toutes les possibilites et si on pouvait y acceder par la suite pour juste une ou deux possibilites ? mais en gardant les meme champs de recherche et de test.

Merci encore pour l'aide que vous m'apporter.

John.

[SheikYerbouti]

Vous pouvez créer toutes les vues que vous voulez.

la question est pourquoi cette vue doit être créée dynamiquement ?

[Simeans2004]

En fait, j'ai un formulaire internet qui me permet de filtrer une requete de facon a obtenir un rapport issue de la base oracle.

cependant, ce rapport qui est toujours cree a partir de la meme requete, varie en fonction de la duree sur laquelle on le demande.

aussi je voulais savoir si en faisant une materialized view qui s'etend sur une annee, ma requete qui elle sera de 2 semaines sur cette annee fera t elle appelle a la materialized view ou non?

[SheikYerbouti]

La requête fera appel à la table ou à la vue que vous aurez spécifié dans votre requête !

Si je comprend bien, les champs composant votre vue sont uniques, c'est simplement une restriction que vous souhaitez faire dans ces données avec une clause where ?

un exemple concrêt des données dont vous avez besoin serait appréciable

[Simeans2004]

Oui c'est exactement cela :

en fait j'ai une dizaine de tables contenant des bon de commandes, les fournisseurs, les clients, ... tout ce qui s'y rapporte.

Mon formulaire web me permet de selectionner un fournisseur ou un client, et en fonction de ce choix j'obtiendrai des informations specifiques a ce client ou ce fournisseur.

Donc ma question est : est ce que si je fais une materialized view qui contient tous les champs que je recherche mais pour tous les fournisseurs ou pour tous les clients, est ce que lorsque j'effectuerai une requete pour un seul fournisseur, son execution fera appel a la mterialized view ou pas ?

[Simeans2004]

Voila ma definition de la materialized view :

create materialized view test
build immediate
refresh force
enable query rewrite
as
SELECT
DISTINCT S.NAME as SupplierName,
BORG.BORGNAME,
ba.ancestorid,
DECODE(SUBSTR(CSE.SUPPLIERCODE, 1, 1), '1', 'Internal', '6', 'RoundTrip With Catalog', '7', 'RoundTrip', '8', '-', '9', '-', 'Market Site') as SupplierType,
DECODE( NVL(PRICECATALOGNAME, 'NO_PRICECATALOGNAME'), 'NO_PRICECATALOGNAME', 'No Catalog', 'Catalog') as Catalog,
C.COUNTRYNAME as CountryName
FROM
EBO.SUPPLIER S,
ebo.borg_supplier_options bso,
EBO.Cat_Buyer_Account,
ebo.borgancestor ba,
EBO.BORG,
EBO.ADDRESS A,
EBO.COUNTRY C,
EBO.CUSTOM_SUPPLIEREXT CSE,
ebo.cat_pricecatalog b
WHERE
bso.supplierid = s.supplierid and
bso.borgid = ba.borgid and
BORG.BORGID = bso.borgid AND
BORG.DEFAULT_CATSPACEID = Cat_Buyer_Account.CATSPACEID AND
Cat_Buyer_Account.SUPPLIERID = bso."SUPPLIERID" AND
CSE.supplierid = bso.supplierid AND
s.addressid = a.addressid AND
c.countrycode = a.countrycode AND
s.SUPPLIERID = b.SUPPLIERID (+)
ORDER BY
SupplierName ASC,
BORG.BORGNAME ASC

Et voila la requete qui y fait appel :
SELECT
DISTINCT
SupplierName,
BORGNAME,
ancestorid,
SupplierType,
Catalog,
CountryName
FROM
ebo.test
WHERE
ancestorid = #ma variable#
ORDER BY
SupplierName ASC,
BORG.BORGNAME ASC

[Simeans2004]

Cependant, la reponse est encore plus lente avec la materialized view que si je lance la requete normalement....

[SheikYerbouti]

Pourquoi n'utilisez-vous pas une vue simple ? le volume des données est vraiment important ? et les index ?

[Simeans2004]

oui le volume de donnee se chiffre en millier
mais le but en fait c'est d'optimiser la requete grace a la materialized view. Mais pour l'instant c beaucoup plus lent de passer par la vue que par la requete de base :

SELECT
DISTINCT S.NAME as SupplierName,
BORG.BORGNAME,
DECODE(SUBSTR(CSE.SUPPLIERCODE, 1, 1), '1', 'Internal', '6', 'RoundTrip With Catalog', '7', 'RoundTrip', '8', '-', '9', '-', 'Market Site') as SupplierType,
DECODE( NVL(PRICECATALOGNAME, 'NO_PRICECATALOGNAME'), 'NO_PRICECATALOGNAME', 'No Catalog', 'Catalog') as Catalog,
C.COUNTRYNAME as CountryName
FROM
EBO.SUPPLIER S,
ebo.borg_supplier_options bso,
EBO.Cat_Buyer_Account,
ebo.borgancestor ba,
EBO.BORG,
EBO.ADDRESS A,
EBO.COUNTRY C,
EBO.CUSTOM_SUPPLIEREXT CSE,
ebo.cat_pricecatalog b
WHERE
bso.supplierid = s.supplierid and
bso.borgid = ba.borgid and
ba.ancestorid IN ( #Form.BorgList# ) AND
BORG.BORGID = bso.borgid AND
BORG.DEFAULT_CATSPACEID = Cat_Buyer_Account.CATSPACEID AND
Cat_Buyer_Account.SUPPLIERID = bso."SUPPLIERID" AND
CSE.supplierid = bso.supplierid AND
s.addressid = a.addressid AND
c.countrycode = a.countrycode AND
s.SUPPLIERID = b.SUPPLIERID (+)
ORDER BY
SupplierName ASC,
BORG.BORGNAME ASC

c'est presque la meme requete que pour creer la vue mais avec 2 lignes differentes, et elle est prend 2 sec a s'executer, l'appel a la vue, 35 sec en moyenne. Donc j'aimerais connaitre le reel interet des vues ?
je suis desole, je suppose que je dois mal m'y prendre.

merci pour le temps passer a me lire.

[SheikYerbouti]

Vous n'avez pas répondu à la question.

Pourquoi voulez-vous utiliser à tout pris une vue matérialisée ( MATERIALIZED_VIEW) et pas une vue simple (VIEW) ?

[Simeans2004]

excuser moi,
en fait je ne veux pas specialement utilise une vue materialisee, mais on m'a demander de le tester pour voir si ca ne pouvait pas ameliorer les performances.

En me documentant, tout me laissait a penser que les vues materialisees etaient "geniales". Cependant pour l'instant, ce que je remarque c'est que pour des requetes complexes, ce n'est pas du tout le cas.

Est ce que les vues seraient plus appropriees ?

[SheikYerbouti]

Le principe de la vue matérialisée repose sur le fait que la vue est stockée sur disque (correspondant donc quasiment à une table)
la création de la vue matérialisée prend le temps qu'il faut, sachant qu'ensuite elle doit être raffraîchie complètement ou partiellement ce qui prend évidement ensuite moins de temps.
les vues matérialisées sont généralement utilisées sur les datawharehouse.

Si vous ne devez utiliser cette vue que le temps de votre traitement, alors une vue simple ou une requête direct sur les tables fera parfaitement l'affaire

[Simeans2004]

le probleme c'est que nos requetes sont toutes plus ou moins complexes et l'exemple que je vous ai donne est l'une des moins complexe.

Certaines prennent en compte une certaine periode de temps en plus du choix du fournisseur.

Aussi elles peuvent prendre 2 a 3 minutes pour s'executer.
Ce qui est trop long pour certain des internautes (modem 56k).

Aussi on se demandais si il n'etait pas preferable de faire des materialized view sur certaine periode de temps (une par an par exemple) et ainsi on aurait juste a aller tout recuperer dedans. mais ce n'est pas tres rapide, donc auccun interet pour l'instant.

Aussi je me demandais si on ne pouvait pas optimiser les requetes.
Nous avons deja creer nos index et on les utilise deja.

voila, je pense que j'ai a peu pres tout dit...

Si vous avez une idee ?

Sinon encore merci pour le temps passer a repondre.