Bonjour à tous,
 
Pour la première fois je tente d'inclure un système d'historique sur ma DB pour avoir une trace des updates effectués sur la base de données par les utilisateurs.
 
Dans cet exemple l'utilisateur peut modifier les valeurs des tables suivantes. :
'ficheRef', 'adresse', 'contact', 'news', 'usager', 'missionRef', 'catRef'.
 
Elles sont toutes reliées à une table 'historique' avec une cardinalité 0,1 -- 0,N  (sauf la table 'usager' dont je veux impérativement récupérer la clé primaire pour chaque historique).  (voir le lien vers le schéma, ci-dessous)
 

 
Je compte donc utiliser cette table historique grâce à des triggers:
 
Sur chaque table, dès que le champ 'dateModif[I]matable[/I]' est modifié,
- insérer l'id de la table modifiée dans l'historique
- insérer l'id de la table 'usager' dans l'historique
- appliquer un CURRENT_TIMESTAMP dans le champ 'dateModification' de l'historique.
 
Est-ce que ce raisonnement vous parait cohérent? Voyez vous des modifications a apporter à cette façon de faire?
 
Cordialement.

Perso, la table de log que j'ai fait pour mon logiciel de help-desk Astres (cf ma signature) a la structure suivante :
 

CREATE TABLE `LogEvents` (
  `LogEventID` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `LogEventDate` datetime NOT NULL,
  `LogEventItemID` int(10) UNSIGNED NOT NULL,
  `LogEventItemType` varchar(30) NOT NULL,
  `LogEventService` varchar(30) NOT NULL,
  `LogEventAction` varchar(30) NOT NULL,
  `LogEventLevel` tinyint(3) UNSIGNED NOT NULL DEFAULT '5',
  `LogEventTitle` varchar(255) DEFAULT NULL,
  `LogEventDescription` mediumtext,
  `LogEventLinkedObjectID` int(10) UNSIGNED DEFAULT NULL,
  `SupportMemberID` smallint(5) UNSIGNED NOT NULL,
  PRIMARY KEY  (`LogEventID`),
  KEY `SupportMemberID` (`SupportMemberID`),
  KEY `LogEventItemID` (`LogEventItemID`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1;

 
SupportMemberID est l'ID de l'utilisateur ayant fait la modif
LogEventItemID est l'ID de l'enregistrement créé/modifié/supprimé
LogEventItemType est le type d'enregistrement (en gros, la table concernée)
LogEventService est le nom du "module" concernée (un module ayant ses fonctions assurées par une ou plusieurs tables)
LogEventAction est le nom de l'action réalisée (ajout, modif, suppr...)
LogEventLevel est le niveau de l'action (certaines actions étant plus importantes que d'autres, ça sert à filtrer les logs important de ceux qui le sont moins)
LogEventTitle contient un petit message résumant l'action effectuée, très utile quand il s'agit d'une suppression (forcément, plus possible de faire une jointure sur un enregistrement qui n'existe plus )
LogEventDescription contient plus de détails sur l'action, souvent pas rempli, mais utile dans certains cas, par ex, pour stocker le corps d'un mail envoyé.
 
A noter que LogEventTitle et LogEventDescription me servent aussi pour la génération de flux RSS. Ma table fait une pierre 2 coups : un mécanisme de logs et permet de générer différents flux RSS (d'où les champs LogEventItemType, LogEventService et LogEventService qui me permettent de filtrer pour avoir des flux RSS spécifiques).
 

@rufo : en effet belle table de log! De bonnes idées je vais surement essayer d'en transposer certaines.
 
Par contre on me dit que je dois directement lier la table 'usager' à toutes les tables que je veux relier à 'historique' pour avoir l'idUsager. Sinon , parait-il, je ne pourrais pas récupérer l'id de l'utilisateur.  
 
Ca vous parait crédible?

Ca dépend.
 
Perso, ma table de log est venues bien après la création du soft. Donc, pour la plupart des tables qui nécessitaient d'avoir l'ID de celui qui avait créé l'enregistrement, j'avais effectivement un lien entre ces tables et l'équivalent de votre table "usagers" (dans mon cas, SupportMembers).
 
maintenant, si 'es en début de conception, si t'as une table qui logue les créations/maj/suppr des enregistrements dans différentes tables, c'est pas la peine de lier ces tables à "usagers" puisque la table histo sera déjà liée à la table "usagers". Du coup, pour connaître le créateur d'un enregistrement ID=xxxx dans la table = yyyy, il suffit de regarder dans la table histo quel est l'ID usager associé à l'enregistrement xxx pour la table yyyy D'où la nécessité de tracer dans la table de log le type d'action et la table concernée...