Discussion :

[pierrot_d]

Bonjour à tous.

J'ai trouvé dans un coin de ma mémoire, la trace d'une possibilité d'obtenir, via les tables système du SGBD, l'âge (ou la date de création) d'un enregistrement donné.
Cela parle-t-il à quelqu'un, ou est-ce un fantasme créé artificiellement par un cerveau en surcharge ?

Merci d'avance.

[escartefigue]

Bonjour,

La seule façon de connaitre la date et l'heure de création d'une ligne de BDD et la date et l'heure de MàJ de cette ligne, est d'avoir des colonnes dédiées à cet usage dans les tables
Ces colonnes peuvent éventuellement être alimentées automatiquement au moyen de trigger, sinon c'est à l'application de s'en charger.

Le journal de transaction, en fonction du SGBD que vous utilisez, permet de connaître les modifications effectuées, mais il n'a pas vocation à moucharder l'horodatage pour une utilisation fonctionnelle.

[pierrot_d]

Arrrgh !

J'espérais attendre encore un peu avant de prendre des vacances...
Merci pour ta réponse.

[François DORIN]

Bonjour,

La seule façon de connaitre la date et l'heure de création d'une ligne de BDD et la date et l'heure de MàJ de cette ligne, est d'avoir des colonnes dédiées à cet usage dans les tables
Ces colonnes peuvent éventuellement être alimentées automatiquement au moyen de trigger, sinon c'est à l'application de s'en charger.

Il y a la possibilité aussi de préciser une valeur par défaut correspondant à la date au moment de l'enregistrement.

Par exemple, sous SQL Server :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE dated_row(
id INT IDENTITY,
date_creation DATETIME2 DEFAULT GETDATE(),
PRIMARY KEY(id)
);
 
INSERT INTO dated_row DEFAULT VALUES;

La ligne insérée aura automatiquement la colonne date_creation de renseignée.

En plus d'être plus légère, je préfère cette approche à celle des triggers pour des raisons de maintenance.

[escartefigue]

@ Dorinf : je suis d'accord, c'est une solution à la fois fiable et économe en maintenance

Cela étant, il faut aussi connaitre le SGBD, tous ne proposent pas les mêmes fonctionnalités

[pierrot_d]

Ah ouai, ça me plait bien ça.
Merci dorinf.

[François DORIN]

Cela étant, il faut aussi connaitre le SGBD, tous ne proposent pas les mêmes fonctionnalités

Tout à fait, mais j'ai regardé rapidement, et tous les grands (aheum tousse tousse) SGBD supporte cette fonctionnalité. Pardon, j'ai pas regardé pour Oracle, mais pour Postgres, MySQL/MariaDB oui

[SQLpro]

Bonjour,
Il y a la possibilité aussi de préciser une valeur par défaut correspondant à la date au moment de l'enregistrement.

Par exemple, sous SQL Server :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE dated_row(
id INT IDENTITY,
date_creation DATETIME2 DEFAULT GETDATE(),
PRIMARY KEY(id)
);
 
INSERT INTO dated_row DEFAULT VALUES;

La ligne insérée aura automatiquement la colonne date_creation de renseignée.

En plus d'être plus légère, je préfère cette approche à celle des triggers pour des raisons de maintenance.

Il y a beaucoup mieux !!!! En effet la norme SQL 2011 a entériné le principe des tables temporelles, c'est à dire des tables dotées de propriétés de traçage automatique des INSERT, UPDATE et DELETE dans le temps !
À l'aide de ce mécanisme, la table ainsi temporalisée se voit dotée de 2 nouvelles colonnes début et fin. La date début étant celle de l'insertion et la date de fin toujours du 9999-12-31 0h
En cas d'update, la date de début est réajustée à l'heure de l'update et une table d'historisation créé automatiquement pour ce besoin, reçoit l'ancienne ligne avec les valeurs passées, y compris date de début et comme date de fin celle de l'UPDATE.
En cas de delete, la ligne est réellement supprimée de la table et reportée dans la table d'historisation avec comme date de fin celle du DELETE.
Pour parfaire ce mécansime, des opérateurs temporels spéciaux permetent de "voir" les données à tout instant du temps.

Ceci est implémenté dans SQL Server 2016 tel quel, dans oracle à la sauce Oracle, mais ni dans MySQmerde ni Dans PostGreSQL...

A +