Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je cherche a cacher 2 colonnes :
supposons que j'ai 100 colonnes de a1 à a100 et je ne veux cacher que a2 et a3
quelle est l'ecriture du GRANT select ?
merci
Hors ligne
bon j'ai fait une proc en pg/sql si ca interesse?
Hors ligne
Il suffit d'utiliser une vue ! Une vue c'est une requête SELECT sur une table (ou plusieurs) et les vues peuvent être mise à jour (INSERT, UPDATE, DELETE).
C'est du SQL de base.
Pour apprendre le SQL, mon site web, comme mon bouquin, peuvent vous être utile.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Le droit sur les colonnes est plus intéressant que les vues qui cache des colonnes. Le premier ne souffre pas de la limitation du second qui est qu'il est toujours possible de voir les valeurs d'une colonne non affichée en faisant un filtre sur celle-ci. Par exemple, si la vue v1 affiche toute la table t1 sous la colonne c2, je peux quand même connaître les lignes pour lesquelles la colonne c2 a la valeur 5 (par exemple) : SELECT * FROM v1 WHERE c2=5. Ce ne serait pas le cas avec des vues matérialisées mais comme les vues sous PostgreSQL ne peuvent pas être matérialisées (sauf astuce), on ne peut pas à coup sûr empêcher de visualiser le contenu d'une colonne avec une vue. D'où les droits sur les colonnes.
Guillaume.
Hors ligne
Si vous n'avez pas le privilège de SELECT sur la colonne C2 alors le WHERE C2 = 5 devrait conduire à une erreur ! En effet par ce biais vous pourriez donc connaître les valeurs des lignes pour lesquelles C2=5, alors qu'on en interdirait la lecture, ce qui est donc parfaitement absurde !!! Je n'ai pas fait l'essai, mi si c'est le cas dans PG, alors c'est un bug de sécurité très important !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Si vous n'avez pas le privilège de SELECT sur la colonne C2 alors le WHERE C2 = 5 devrait conduire à une erreur !
C'est bien le cas. Ce n'est pas ce que je dis. Ce que je dis, c'est que dans le cas d'une vue, c'est possible de faire le test sur une colonne qui n'est pas récupéré par la vue. Donc il vaut mieux se baser sur les droits sur les colonnes pour une vraie protection.
Guillaume.
Hors ligne
Hé bien si c'était le cas c'est une aberration de PG ! En effet, sur une vue vous ne pouvez manipuler aucune des colonnes auquel la vue ne fait pas référence explicitement.
Voici un exemple et ce à quoi il devrait conduire :
CREATE TABLE T(C1 INT, C2 INT);
INSERT INTO T VALUES (1, 1);
INSERT INTO T VALUES (2, 2);
CREATE VIEW V
AS
SELECT C1 FROM T;
SELECT *
FROM V
WHERE C2 = 1.
Ceci devrait causer une erreur du genre : "Nom de colonne non valide : 'C2'."
C'est d'ailleurs bien le cas dans la version 8.4 !
ERREUR: la colonne « c2 » n'existe pas
LINE 3: WHERE C2 = 1
^
********** Erreur **********
ERREUR: la colonne « c2 » n'existe pas
État SQL :42703
Caractère : 26
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ah oui, en effet, me suis planté là-dessus. Désolé.
Guillaume.
Hors ligne
Bon, par contre, il y a quelques points qu'il me semble utiles de préciser:
- La méthode avec la vue ne marche que si on n'a pas trop de profils de droits d'accès à la table, mais seulement un ou deux: on peut imaginer créer et maintenir 2 vues pour gérer les droits. Si il y a une dizaine de types d'accès, on ne va pas maintenir la combinaison de toutes les vues possibles pour tous les types d'accès. C'est bien plus simple de définir des rôles, et de faire des grants de colonnes à ces rôles. On est d'accord, ça n'arrive pas souvent.
- La méthode avec les vues impose de reconstruire les vues à chaque modification de la table de base, pour que les nouvelles colonnes apparaissent. Utiliser des vues, c'est quand même plutôt une méthode détournée, comme faire des liens sur un binaire dans un système de fichiers ne possédant pas d'ACL. Du moins à mon avis.
- Les vues ne sont pas modifiables sous Postgres. À moins d'écrire des rules pour le moment (c'est très sujet à erreur, sauf dans les cas simples, et déconseillé même par les développeurs de PostgreSQL), ou des triggers seront possibles en 9.1… ce qui ouvre la voie à des vues modifiables proprement dans un futur proche. Puis certainement à une implémentation automatique dans le moteur.
Marc.
Hors ligne
...Utiliser des vues, c'est quand même plutôt une méthode détournée, comme faire des liens sur un binaire dans un système de fichiers ne possédant pas d'ACL. Du moins à mon avis.
Sauf que vous oubliez que la conception des bases de données relationelle repose justement sur la notion de vues !
Les 4 étages de la modélisation sont :
1) le MCD (modèle ceonceptuel de données) : entité + association, avec la notation que vous voulez : Merise, UML, ER...
2) le MLD (modèle logique de données), c'est à dire les relations au sens mathématique
3) le MPD (modèle physique de données) c'est à dire les tables, index, contraintes...
4) le MED ou modèle externe de donné, grand oublié, c'est à dire les vues. En fait c'est à partir des vues que toute application devrait être écrite !
Sur l'importance des vues, je vous invite à relire les 12 règles de Codd, père fondateur des SGBDR... Vous serez étonné de voir que sur 12 règles, au moins 4 parlent des vues. http://sqlpro.developpez.com/SGBDR/ReglesCodd/
Dommage que PG soit en retard par rapport aux grand SGBDR comme Oracle, SQL Server, IBM Db2 ou Sybase sur ce sujet, notamment sur la misajourabilité des vues !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pages : 1
