Discussion :

[DemonSurf]

Bonjour à tous.

J'explique mon problème : j'ai besoin de pouvoir contrôler la date de la dernière modification des tables de ma BDD.

Je fais déjà une requête pour connaître la date de la dernière modification de la structure des tables, avec :

Code PHP :

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

1
2
3
4
5
6
7
8
$SQL = "SHOW TABLE STATUS FROM " . $BDD;
$valeurs_info = mysql_query($SQL);
 
while($valeurs = mysql_fetch_assoc($valeurs_info))
{
    echo $valeurs['Name'] . "<br />";
    echo $valeurs['Update_time'] . "<br /><br />";
}

Cependant, j'ai également besoin de connaître la date de la dernière modification des données elles-même (INSERT INTO, UPDATE ou DELETE).

Cette information m'est essentielle afin de poursuivre le développement de mon application, aussi n'hésitez pas si vous avec une idée sur la question, ou que vous désirez d'avantage de précisions.

Merci d'avance.

[Waldar]

C'est à vous d'ajouter les colonnes de contrôles qui vous vont bien !

[DemonSurf]

Si vous entendez par là insérer des champs "date" et "heure", ou "timestamp" dans les tables, ce n'est pas possible ; je ne peux pas intervenir sur leurs structures.

Mon application possède sa propre base de données locale, et doit la mettre à jour si des changements surviennent sur celle en ligne (afin de pouvoir faire des traitements hors ligne le cas échéant) ; c'est une vérification qu'elle fait à son lancement. Elle doit être en mesure de repérer toute modification (de structure ou de données) en fonction d'une date/heure de dernière modification des tables, individuellement, pour ne télécharger que le stricte nécessaire.

Il m'est impossible de demander aux modérateurs de cette base de donnée en ligne de penser à mettre des dates/heures à chaque modification, j'ai besoin d'une requête le révélant.

Il n'y existerait donc pas de requête pour cela ? Je travail sur des serveurs Wamp, avec MySQL, ces informations ne sont pas sauvegardées et récupérables par le biais d'une commande ?

[CinePhil]

La base information_schema contient les métadonnées de tout ce qui est hébergé sur le SGBD.
La table TABLES contient des colonnes CREATE_TIME et UPDATE_TIME.

[SQLpro]

Si vous entendez par là insérer des champs "date" et "heure", ou "timestamp" dans les tables, ce n'est pas possible ; je ne peux pas intervenir sur leurs structures.

[...]

Il m'est impossible de demander aux modérateurs de cette base de donnée en ligne de penser à mettre des dates/heures à chaque modification, j'ai besoin d'une requête le révélant.

Il n'y existerait donc pas de requête pour cela ? Je travail sur des serveurs Wamp, avec MySQL, ces informations ne sont pas sauvegardées et récupérables par le biais d'une commande ?

Dans une base de données, vous ne trouverez que les informations que vous y mettrez. Par essence un SGBDR ne rajoute pas certaines informations en dehors des méta données des bases (structures de la base - voire vues d'information de schéma). C'est donc à vous de rajouter les colonnes nécessaire aux fonctionnalités souhaitées.

A +

[fsmrel]

Quel que soit le SGBD, il y a quand même les fichiers LOG dans lesquels on retouve les "Points in time" des opérations de mise à jour, non ?

[al1_24]

Mais là, on est très loin des définitions du langage SQL. Plutôt les pieds dans la glaise de l'implémentation de chaque SGBD

[fsmrel]

Mais là, on est très loin des définitions du langage SQL. Plutôt les pieds dans la glaise de l'implémentation de chaque SGBD

Je suis d’accord, on devrait avoir accès à l’information avec SQL.

Prenons le cas du Modèle Relationnel de Données. On y trouve la proposition suivante en Tutorial D (et que l’on dois sûrement trouver chez différents chercheurs et auteurs traitant des données temporelles), que je transcris ici en SQL :

Code :

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

1
2
3
4
5
6
7
8
9
 
CREATE TABLE ENTREPRISE
 (
      EntrepriseID    INTEGER       NOT NULL
    , Raison_Sociale  VARCHAR(48)   NOT NULL
    , ...
  , PRIMARY KEY (EntrepriseID) 
  , LOGGED_TIME_IN (ENTREPRISE_LOG)
 ) ;

La clause LOGGED_TIME sert à nommer une table de type log, journal, audit, etc. permettant de tracer le vécu des lignes de la table ENTREPRISE. Évidemment, nous n’avons que le droit de consulter la table ENTREPRISE_LOG (avec SQL bien sûr), complètement gérée par le système.

Je ne sais pas si la norme SQL et les SGBDR proposent quelque chose de ce genre. Cela dit, sans une clause du genre LOGGED_TIME, comment DemonSurf pourrait-il savoir qu’une entreprise a été supprimée à telle date, si cette date de suppression est gérée par lui dans une colonne (et dans la ligne concernée) de la table ENTREPRISE ?

Il lui reste la solution du trigger : à chaque INSERT, UPDATE, DELETE portant sur la table Entreprise, grâce au trigger qui va bien, on intercepte l’opération pour en noter la date et l’heure dans sa propre table ENTREPRISE_LOG, mais avec tous les aléas induits par exemple par les ROLLBACK, suite à abandon de transaction, etc.

Sinon, comme je l’ai évoqué, il lui reste l’exploitation des logs. S’il utilise DB2 for z/OS, il existe des outils pour ça. Pour les autres SGBD, voir ce que proposent les éditeurs...