Discussion :

[ftrifiro]

Bonjour,

J'espère être dans le bon forum pour poser ma question... Nul doute qu'elle a concerné ou concernera chacun de nous à un moment ou à un autre. Imaginons une gestion d'historique...

A chaque modification d'une ligne, on historise la ligne en gardant la précédente et en créant une nouvelle correspondant aux informations à jour. Ma question est la suivante :

Est-il souhaitable pour des questions de performance ou même de conception d'avoir deux tables : une pour gérer les données courantes et une pour gérer les données historisées ? Ou bien est-ce superflu, voire un mauvais choix ?

La base est sous Oracle, la volumétrie est en vitesse de croisière de quelques centaines de milliers de lignes, historique compris.

Merci pour vos avis, Frédéric

[SQLpro]

Si vous archivez la ligne complète alors base secondaire ...

Exemple : base de prod de nom toto, base archive de nom toto_histo

Sinon, vous pouvez ne sauvegarder que le delta dans des tables particulières dont la structure peut être la suivante :

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE T_HISTORIQUE_HST
(HST_ID               BIGINT NOT NULL PRIMARY KEY,
 HST_DATE_HEURE       TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
 HST_ACTION_ID        INTEGER NOT NULL FOREIGN KEY REFERENCE -- table des action : UPDATE, DELETE...
 HST_LOT_ID           INTEGER NOT NULL -- identifiant du lot
 HST_TABLE_ID         INTEGER NOT NULL FOREIGN KEY REFERENCE -- table des tables 
 HST_COL_ID           INTEGER NOT NULL FOREIGN KEY REFERENCE -- table des colonnes des tables 
 HST_TYPE_SQL_ID      INTEGER NOT NULL FOREIGN KEY REFERENCE -- table des types SQL et des DOMAINES
 HST_VALUE            NVARCHAR(4000))

Ceci suppose que vous allez ajouter plusieurs tables dont une pour calculer la clef du lot.
Par exemple lors de la suppression d'une ligne d'une table, le n° du lot sera le même pour toutes les valeurs supprimée.

A +

[Médiat]

Est-il souhaitable pour des questions de performance ou même de conception d'avoir deux tables : une pour gérer les données courantes et une pour gérer les données historisées ? Ou bien est-ce superflu, voire un mauvais choix ?

En tout état de cause, et quelle que soit la solution choisie, il y a un piège dans lequel il ne faut pas tomber, c'est de modifier la sémantique d'une table.
Je donne un exemple : Une table client (clé = IdClient) dont tu veux historiser le status (Bon client, douteux, mauvais), si tu décides de tout mettre dans la table client, avec une nouvelle clé (IdClient, DateEffet), ce n'est plus une table des Clients que tu as, mais une table des états des clients (glissement sémantique). Il est beaucoup plus sain d'avoir une table des clients (clé = IdClient) + une table des états (clé = IdClient, DateEffet). La question qui reste à trancher est : comment retrouver l'état courant ?

• 1) Dans la table des états (historique homogène, état courant au travers d'une jointure), on le retrouve :
  [list:3c4bb81df6]a) Avec la Date la plus grande (pas le plus efficace)
  b) Avec un flag (mise à jour complexe (il faut mettre à jour une ligne avant d'en insérer une autre).
  c) Avec la DateEffet dans la table Client pour pointer sur le bon enregistrement (j'aime bien, en plus la PK va créer un index bien utile)
  d) Avec un N° d'ordre pour tous les enregistrements de la table Etat, et le N° de l'état courant dans la table Client (pk plus efficace pour les jointures, mais il faudra sans doute créer l'index (IdClient, DateEffet), pour les recherches (dans le cas des états la volumétrie est faible, mais dans d'autres situation cela peut devenir crucial))
  e) Mettre DateDébut et DateFin dans la table des états, à la place de DateEffet, y compris pour la valeur courante (DateFin = 31/12/2999), même problème que le flag pour la mise à jour, mais la recherche de l'état à une date donnée est très simplifié

2) Dans la table Client uniquement (historique pas homogène)
3) Dans la table client et dans la table des états (duplication)[/list:u:3c4bb81df6]

[ftrifiro]

Tout à fait d'accord pour le glissement sémantique à éviter absolument. Mais je n'ai pas le problème en fait. Je stocke déjà des états de dossiers dont le plus récent est le courant...

Merci

[isayus]

remarque très pertinante à propos du glissement sémantique

merci