impossible de modifier les données d'une vue

[lepierot]

Bonjour,
j'ai créé une vue sur une table, et avec toad je ne peux pas modifier les données. Les zones de saisie de Toad semble comme blockées !!!

[orafrance]

on ne peut pas updater une vue... une vue c'est qu'une requête SQL stockée en base et exécuté à chaque SELECT de la vue, comment Oracle pourrait-il mettre à jour des données non stockées ?

[lepierot]

Pas du tout, dans certain cas on peut modifier une vue :

faite le test suivant :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
SQL> CREATE TABLE MARKETING.AA
  2  (
  3      NOM    VARCHAR2(15)     NULL,
  4      PRENOM VARCHAR2(15)     NULL
  5  )
  6  /
 
TABLE crÚÚe.
 
SQL> CREATE OR REPLACE VIEW MARKETING.VUE_AA
  2  (
  3      NOM,
  4      PRENOM
  5  )
  6  AS
  7  SELECT "NOM","PRENOM"
  8        FROM aa
  9  /
 
Vue crÚÚe.
 
SQL> INSERT INTO AA (nom,prenom) VALUES ('tigger','scott');
 
1 ligne crÚÚe.
 
SQL> commit
  2  ;
 
Validation effectuÚe.
 
SQL> INSERT INTO vue_AA (nom,prenom) VALUES ('tigger2','scott2');
 
1 ligne crÚÚe.
 
SQL> commit
  2  ;
 
Validation effectuÚe.
 
SQL>

Avec SQLPLUS et avec ACCESS en attachement ODBC ca marche parfaitement, c'est juste que peut etre Toad bride la chose !!!!

[orafrance]

oui bien sûr, j'ai pas voulu compliqué la chose étant donné que faire un update d'une vue me parait particulièrement être une mauvaise pratique

Pour préciser ce que j'ai dit : on ne peut mettre à jour qu'une vue simple, qui ne contient pas calcul, ni de transformation, ni de jointure, etc...

PS : merci de penser aux balises CODE

[laurentschneider]

Envoyé par orafrance

un update d'une vue me parait particulièrement être une mauvaise pratique

non, ce n'est pas une mauvaise pratique. C'est aussi une façon de restreindre l'accès à seulement certaines colonnes ou lignes de la tables, style BLAKE ne peut mettre à jour que sa ligne et ne voit que certaines colonnes

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
SQL> CREATE VIEW v AS 
  SELECT ENAME, DNAME, JOB, EXTRACT(YEAR FROM HIREDATE) HIREDATE 
  FROM EMP NATURAL JOIN DEPT WHERE ename=user WITH CHECK OPTION;
 
VIEW created.
 
SQL> GRANT SELECT ON v TO blake;
 
GRANT succeeded.
 
SQL>  GRANT UPDATE (job) ON v TO blake;
 
GRANT succeeded.
 
SQL> conn BLAKE/PAPER
SQL> SELECT * FROM scott.v;
ENAME      DNAME          JOB         HIREDATE
---------- -------------- --------- ----------
BLAKE      SALES          MANAGER         1981
 
SQL> UPDATE scott.v SET job='PRESIDENT';
 
1 row updated.
 
SQL> roll
Rollback complete.

Avec Toad, je peux très bien mettre à jour ma vue.

Cependant, comme mentionné par orafrance, de nombreuses conditions rendent la vue inéditable.

[LeoAnderson]

c'est sûr mais le FGA me semble plus approprié et plus propre qu'une vue pour ça, non ?

[laurentschneider]

tu veux dire RLS ?

Row-Level Security (ou Fain Grained Access Control) est disponible avec la version Enterprise et permet d'implémenter la VPD (Virtual Private Database). L'API est DBMS_RLS

FGA c'est l'abréviation de Fain Grained Auditting, avec l'api DBMS_FGA, et ça permet de faire un audit de manière plus élaborée que AUDIT SELECT, car même le SELECT exécuté peut être capturé.

Je pense que d'avoir un role UPDATE sur une vue est tout à fait acceptable. Pas forcément besoin de définir des polices avec DBMS_RLS, ou bien?

J'attends tes commentaires

[orafrance]

Envoyé par laurentschneider

C'est aussi une façon de restreindre l'accès à seulement certaines colonnes ou lignes de la tables, style BLAKE ne peut mettre à jour que sa ligne et ne voit que certaines colonnes

il y a la VPD pour ça

[laurentschneider]

Oui, je ne dis pas que je suis un grand fan des vues (ni lecture-seule ni lecture-écriture), mais si on employe des vues, on peut aussi bien les employer pour l'écriture que la lecture, non?

Bon, si tu ne veux pas qu'on mette à jour tes vues, créée les read-only

Code :

1
2
3
SQL> CREATE VIEW v AS SELECT ename FROM emp WITH READ only;
 
VIEW created.

[orafrance]

le problème de l'écriture dans les vues c'est qu'il y a une grosse faille qui peut permettre de modifier des données via la vue même si le user n'a pas les droits sur la table

[laurentschneider]

1) tu dois avoir les droits sur la vue pour modifier la vue
2) si la vue t'appartient, alors tu ne peux pas modifier la table. Il y avait effectivement un bug qui est fixé depuis quelques années qui permettait d'effacer le contenu d'une table avec seulement les privilège "SELECT" et "CREATE VIEW".

Il ne faut pas donner CREATE VIEW à un utilisateur final, mais créer des vues avec des droits sur la vue et non sur la table ne me pose personnellement pas de problème.

Je trouve que ça augmente la sécurité plus que ça ne la diminue (tu peux masquer certaines colonnes)