Discussion :

[bruno.rotrou]

Bonjour,
Une question qui va peut-être vous paraitre idiote ;-)
Y'a t'il un moyen dans une base de donnée d'interdire la modification d'une donnée.
Exemple j'ai un champs date, une fois écrit il n'est plus modifiable ....
Merci d'avance pour vos lumières

[CinePhil]

Les champs sont à la campagne ou dans les formulaires ; pas dans les tables des bases de données qui ne sont composées que de colonnes et de lignes !

Pour répondre à votre question : oui, c'est possible à l'aide d'un trigger avant mise à jour qui ignorera la mise à jour de la colonne date souhaitée, même si la requête update spécifie une valeur pour cette colonne.

[bruno.rotrou]

Merci pour cette réponse.
Je ne savais pas que j'allais tomber sur qq du milieu agricole, et qui est très attentif aux champs ;-)
Merci encore je regarde ça de prés, j'imagine que tout les SGBD utilisent des triggers.

[CinePhil]

Je ne suis pas sûr qu'Access utilise un mécanisme équivalent aux triggers (ça fait un bon paquet d'années que je n'utilise plus Access), pas plus que Open/Libre Office Base. Sqlite, je ne sais pas du tout. Les autres SGBD plus conséquents (même le très moyen MySQL/MariaDB) connaissent des triggers.

Quel SGBD utilisez-vous ?

[SQLpro]

Pas uniquement par déclencheur.

En effet, vous pouvez faire ceci par le biais des privilèges. Ce sera beaucoup plus efficace ! Démonstration (avec MS SQL Server)...
Création des objets et privilèges :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE T (C1 INT, C2 INT, C3 DATE DEFAULT CURRENT_TIMESTAMP);
GO
CREATE USER toto WITHOUT LOGIN;
GO
GRANT SELECT, INSERT, DELETE ON T TO toto;
GO
GRANT UPDATE ON T (C1, C2) TO toto;
GO

Manipulation des données :

Code :

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

1
2
3
4
5
6
7
8
9
10
--> simulation d'une connexion avec l'utilisateur toto
EXECUTE AS USER = 'toto'
 
INSERT INTO T 
VALUES (0, 0, '1999-12-31'),
       (1, 1, '2001-01-01');
 
UPDATE T SET C2 = 10 WHERE C1 = 1;
 
UPDATE T SET C3 = CURRENT_TIMESTAMP;

Toutes ces commandes se déroulent bien, sauf la dernière :

Msg*230, Niveau*14, État*1, Ligne*21
L'autorisation UPDATE a été refusée sur la colonne «*C3*» de l'objet «*T*», base de données «*tempdb*», schéma «*dbo*».


Dans certains SGBDR avancés, on peut être aussi beaucoup plus générique en privilégiant de la sorte… Au lieu du GRANT UPDATE ON T (C1, C2) TO toto;, on fait :

Code :

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

1
2
3
GRANT UPDATE ON T TO toto;
 
DENY UPDATE ON R (C3) TO toto;

Ainsi, si de nouvelles colonnes sont créées dans la table, l'UPDATE restera actif pour toto sur ces nouvelles colonnes, sans être obligé de rajouter des commandes pour gérer les nouveaux privilèges sur les nouvelles colonnes.

Enfin, si cette date est une date d'historique d'insertion de la ligne, intéressez vous aux tables temporelles (rien à voir avec les tables temporaires), qui permettent d'historiser de manière automatique sans que l'utilisateur fasse quoi que ce soit, et sans que l'utilisateur puissent modifier ces informations… Les tales temporelles sont arrivées avec la norme SQL 2011 mais tous les SGBDR ne les implémentent pas…


A +

[bruno.rotrou]

Merci bcp pour cette nouvelle approche.
pour répondre a @CinePhil J'utilise mySql.

Merci a tous les deux je vais tester ca sur mySql
A+

[SQLpro]

Pour un exemple sur les tables temporelles (avec SQL Server) :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE T_CLIENT   
(CLI_ID             INT IDENTITY PRIMARY KEY,
 CLI_NOM            VARCHAR(32),
 _DH_VALIDE_DEBUT   DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN,
 _DH_VALIDE_FIN     DATETIME2 GENERATED ALWAYS AS ROW END   HIDDEN,  
 PERIOD FOR SYSTEM_TIME (_DH_VALIDE_DEBUT, _DH_VALIDE_FIN)  
 )    
 WITH (SYSTEM_VERSIONING = ON);

La table à deux colonnes supplémentaire indiquant pour chaque ligne l'intervalle de validité, avec des colonnes autoalimentées et cachées (non vues dans un SELECT *).

Code :

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

1
2
3
4
5
6
7
8
 
INSERT INTO T_CLIENT VALUES ('Dupont');
 
SELECT * FROM T_CLIENT;
 
CLI_ID      CLI_NOM
----------- --------------------------------
1           Dupont

Insertion des données. Puis SELECT ne montrant pas les colonnes de validité temporelle

Code :

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

1
2
3
4
5
SELECT *, _DH_VALIDE_DEBUT, _DH_VALIDE_FIN FROM T_CLIENT;
 
CLI_ID      CLI_NOM                          _DH_VALIDE_DEBUT            _DH_VALIDE_FIN
----------- -------------------------------- --------------------------- ---------------------------
1           Dupont                           2018-09-12 07:22:19.5824801 9999-12-31 23:59:59.9999999

Affichage des colonnes de validité temporelles…

On peut aussi rajouter une table d'historisation automatique pour voir toutes les informations modifiées (UPDATE, DELETE)…

Code :

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

1
2
3
4
ALTER TABLE T_CLIENT
   SET (SYSTEM_VERSIONING = OFF);
ALTER TABLE T_CLIENT
   SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.T_CLIENT_HISTO));

Dès lors toutes les modifications sont tracées…

Exemple :

Code :

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

1
2
3
4
5
6
7
8
UPDATE T_CLIENT
SET CLI_NOM = 'IBM';
 
SELECT * FROM T_CLIENT_HISTO;
 
CLI_ID      CLI_NOM                          _DH_VALIDE_DEBUT            _DH_VALIDE_FIN
----------- -------------------------------- --------------------------- ---------------------------
1           Dupont                           2018-09-12 07:22:19.5824801 2018-09-12 07:43:36.6737111

A +

[escartefigue]

Une autre façon très simple de répondre à ce besoin est de passer par une vue qui ne déclare pas la colonne de la table dont on souhaite protéger le contenu.

[SQLpro]

Une autre façon très simple de répondre à ce besoin est de passer par une vue qui ne déclare pas la colonne de la table dont on souhaite protéger le contenu.

Oui, mais pas vraiment si simple… ça a été mon premier réflexe… Mais tu doit avoir la vue qui permet l'insert de la colonne, autorise la lecture mais pas l'UPDATE….

A +

[CinePhil]

Merci Fred, je ne connaissais pas tout ça.

bruno.rotrou utilise MySQL. Le GRANT sur une partie de la table y existe aussi ?

[SQLpro]

Normalement c'est du standard basic !
https://dev.mysql.com/doc/refman/5.7/en/grant.html

Donc oui pour MySQmerde… !

A +