Suivre les changements sur une vue

Version imprimable

02/12/2009, 18h08
LEK

Suivre les changements sur une vue

Bonsoir,
je travailles sous oracle 10g et je possède la problématique suivante : j'ai comme base de travail plusieurs vues. Je voulais savoir s'il est possible de détecter lorsque le contenu de ces vues viens à varier ?
La possibilité de rajouter des triggers sur chaque table impliqués dans ces vues n'est pas possible car cela entraine pour nous des problèmes de perfs et de maintenance.
Des triggers sur vue ça existe ? En attendant, la seule idée que j'ai et de sotcker le contenu d'une vue à un temps T puis d'effectuer des vérifications (minus) à intervalle réguliers..

Enfin bon si quelqu'un a déjà eu à gérer ce type de problématique je suis ouvert à toute proposition.
Merci,
Lek.
02/12/2009, 19h23
mnitu

Créez vos vues avec des scripts SQL gérés avec un utilitaire de gestion des versions (Source safe, Subversion, VCS, etc.)
02/12/2009, 20h56
LEK

Merci, mais ce n'est pas le sql des vues lui même que je dois suivre mais bel et bien le résultat (les lignes) que j'obtient lorsque je les interroge.
03/12/2009, 10h03
mnitu

Donc, j'avais mal compris.
Les vues (sauf les materialized vue) ne possèdent pas des données. Donc audit ou triggers ou vues materialisées.
03/12/2009, 10h59
mongilotti

salut, tu dois utilisé les vues materialisés ou les triggers. sinon tu peux pas faire ça.
03/12/2009, 11h28
pacmann

Salut !

Mongilotti, en parcourant les précédents posts, je pensais que tu étais un bot qui dit "merci de marquer ce sujet comme résolu".

Mais je suis rassuré, tu es également capable de répéter la dernière phrase postée... :mrgreen:
03/12/2009, 14h47
mongilotti

salut,
Pacmann les gens on toujours besoin de plus d'une réponse pour qu'il soit rassurer.

8-)
03/12/2009, 16h00
LEK

Ok merci,
donc mon problème reste insoluble car pour les vues matérialisée :
bien que techniquement possible, faire des triggers sur des read-only materialized views (ce qui serait le besoin) n’est pas recommandé.
(visiblement, pas trop compatible / effets de bords avec ce que fait Oracle pour procéder au « refresh » de ces vues, cf ci-dessous)

Citation:

Extrait de http://asktom.oracle.com/pls/asktom/...89600346945045 :

Triggers on a read only materialized view might appear to work - but you cannot rely on them working :
An update of a row in a materialized view might be done as a DELETE+INSERT.
A refresh of a materialized view might involve a delete + insert of every row.
A refresh might involve a truncate plus direct path load of ever row.

(the last two will probably happen sometime, you would lose anything your trigger had done in the past)

You do not know how we refresh, it would be a very shaky proposition to have a trigger on a read only materialized view - I would not recommend it.

Utiliser des triggers ne m'est pas possible car beaucoup trop de tables (400) utilisant parfois des modifications/insertions en masse sont impliquées et volontairement on ne m'a permis de travailler qu'à partir de vues plus ou moins complexes interrogeant ces différentes tables : donc on a peur des problèmes de maintenance et de perf.

J'ai aussi explorer rapidement d'autres solutions comme oracle CDC (trop complexe à mettre en place), flashback query (historique que nous aurions limité dans le temps et non sure : en cas de besoin d'espace disque/memoire oracle privilégie son travail ce qui parait normal)....

Je pense que je vais finir par me construire des tables d'histoques de fortune que je raffraichirais régulièrement...

Mais merci tout de même pour votre aide.
03/12/2009, 16h10
mnitu

Citation:

Envoyé par LEK

...
Je pense que je vais finir par me construire des tables d'histoques de fortune que je raffraichirais régulièrement...

J'avais pensé aux vues materialisée pour remplacer vos "tables d'histoques de fortune".
03/12/2009, 16h19
LEK

Oui tout à fait, j'envisage un fonctionnement similaire mais j'aurais le loisir de stocker plusieurs versions datées : ainsi je pourrais avoir des options du type comparer la version n à la version n-2....
Grosso modo mon besoin est trés proches sinon similaire à de la gestion de version de fichier : je dois pouvoir à l'instant t dire si les lignes restituées par la vue V sont différentes de celles données lors du requêtage en t-1 : et cerise sur le gâteau si je peux donner le diff exact...
03/12/2009, 16h27
Waldar

Je dirai plutôt qu'il faut faire une historisation fine de vos données, au niveau des tables, mais c'est plutôt coûteux comme procédé sur une base OLTP.

Sur une base dédiée type DWH avec un chargement quotidien, c'est moins coûteux.