Fichier de journalisation

[JCD21]

Bonjour.
je développe une base de données avec Oracle et PHP et je voudrais qu'à l'affichage d'une donnée, par exemple un texte, je puisse afficher la personne qui l'a ajouté avec la liste des personnes qui l'ont modifié (avec aussi la date).
Je cherche donc une requête SQL qui connaissant la table et l'identifiant d'une donnée me renvoie la liste des utilisateurs qui ont ajouté/modifié cette donnée.
Est-ce que les fichiers de journalisation permettent de le faire?
Merci.

[McM]

Non, faut que tu le gères toi par trigger dans une table d'historique.

[JCD21]

OK et concrètement, on met quoi dans la table d'historique :comment on fait pour stocker les identifiants qui peuvent être quelconques (nombre, texte, plusieurs nombres) ?

[McM]

Concrètement, tu crées une table à l'identique de la table dont tu veux historiser les modifications, et tu rajoutes une colonne usermaj et datemaj
Un trigger sur ta table X qui insère dans la table historique X_HIST

Code :

1
2
3
4
5
6
7
8
9
CREATE OR REPLACE TRIGGER X_MAJ
BEFORE INSERT OR UPDATE ON X
FOR EACH ROW
DECLARE
BEGIN
	INSERT INTO X_HIST(DATEMAJ, USERMAJ, COL1, COL2..)
  VALUES(USER, SYSDATE, :NEW.col1, :NEW.col2,...);
END;
/

[JCD21]

OK mais j'ai déjà pas mal de tables et donc ça multiplie le nombre de tables par 2. Il n'y a pas un autre moyen avec une seulle table pour l'historique?

[Rams7s]

Une table qui centralise tous les changements de toutes les tables?
Ou repartir les changements sur chacune des tables qui sont surveillées, genre ajouter une nested table pour chacune d'entre-elles?

[McM]

Franchement, ce genre d'historisation est très lourd en terme de volumétrie.
Ce serait possible d'avoir une table d'historique commune, avec USERMAJ, DATEMAJ, TABLENAME, PK, COL, OLD_VALUE, NEW_VALUE par exemple.. mais à mettre à jour c'est pas très pratique, et à utiliser encore plus, et au bout d'une semaine la table fait déjà 1M de lignes.

[Waldar]

Finalement ce que vous voulez, ne serait-ce pas du Fine Grained Auditing ?

Je n'ai personnellement jamais utilisé cette fonctionnalité.

[IndianaAngus]

As tu besoin d'autant de détail?
Parce que sinon tu ajoute à toutes les tables 4 champs:
-utilisateur qui a créer
-date de création
-utilisateur qui a modifier
-date de modification

L'inconvenient c'est que tu as uniquement la dernière personne qui à mis à jour (a toi de voir si c'est un inconvénient).

Sinon tu fait une table ou tu renseigne ces informations pour toutes les tables qui seraient lancé avec un trigger, mais ca risque d'être galère si tu as beaucoup de tables avec des colonnes du type
id, nom table, user modif, date modif.

[JCD21]

Bonjour et merci pour vos réponses. Finalement, je pense que je vais opter pour une table HISTORIQUE qui va contenir le type d’action (ajout, modification, suppression), une description de la donnée ajoutée/modifiée/supprimée, le login de l’auteur, le nom, le prénom, la date.
Je ne vais finalement pas stocker l'identifiant (qui peut être un ou plusieurs nombres selon les cas) de la donnée. Le contenu de la table sera limité à 50 entrées.
Mais j'ai encore une question: l'interface graphique de la base est programmée en PHP: est-ce qu'il vaut mieux faire un trigger pour compléter la table HISTORIQUE ou alors la compléter en PHP?
Merci.