Discussion :

[Nerva]

Bonjour.

Il y a assez longtemps de ça j'avais trouvé sur le site un PDF très intéressant concernant "l'archivage" (ça ne doit pas être le bon terme) des données dans une base et je n'arrive pas à remettre la main dessus. Ce document indiquait comment procéder pour conserver des données originales lorsqu'elles changeaient dans le temps, document que je n'ai malheureusement pas gardé.

Exemple très concret : dans une table de salariés, comment s'y prend t-on quand une femme se marie et change de nom ?

Autre exemple, moins concret mais envisageable : dans une même table, comment fournir des chiffres exacts si le chef de service nous demande combien de salariés habitaient dans telle ville en 2018, sachant qu'il est impossible que personne n'ait déménagé depuis ?

En espérant être clair...

Merci.

[escartefigue]

Bonjour,

Certains SGBD tels que IBM DB2 et MS SQL Server proposent des tables temporelles.
Sinon, selon le besoin, il faut créer une ou plusieurs tables d'historique.
Pour le cas du "changement de nom", on ne remplace jamais le nom de naissance par le nom marital : dans une table des personnes, on prévoit une colonne "nom de naissance" et une colonne "nom d'usage" qui sera "nullable".

[Nerva]

Pour ce qui est de l'adresse, j'avais en quelque sorte une solution sous les yeux qui pourrait fonctionner. Généralement, les adresses sont stockées dans une table T_ADRESSES et les localités dans une table T_LOCALITES. Des clés étrangères s'occupent des relations : T_LOCALITES, T_ADRESSES, T_PERSONNES. Ce qui fait que plusieurs adresses sont saisissables pour une personne. Le but initial n'était pas d'historiser mais de préciser par exemple une adresse pour une résidence principale et une pour une résidence secondaire (ou une adresse de villégiature en semaine et une le week-end). Il suffirait donc d'ajouter une colonne DATE et il serait ainsi facile de gérer un historique des déménagements (ce n'est qu'un exemple parmi tant d'autres). Resterait ensuite à concevoir une requête qui irait chercher les résultats en fonction de différents paramètres.

Pour le nom, j'ai pour habitude de définir 2 colonnes, comme vous précisez, nom de naissance et nom d'usage. Seulement, je fais les choses à l'envers : nom de naissance uniquement pour les femmes mariées. Mais quoi qu'il en soit, ça ne résout pas le problème si le cas suivant se présente :

- En 2001, Mlle Dupont est embauchée dans l'entreprise.
- En 2002, elle devient Mme Durand.
- En 2010, elle divorce.
- En 2015, elle se remarie et devient Mme Dulac.

[escartefigue]

En général on ne s'intéresse guère à l'historique des noms d'usage, mais si toutefois c'est le cas, alors soit on crée une table historique alimentée par traitement, soit on utilise les tables temporelles (si toutefois le SGBD concerné les propose, ce n'est pas le cas de tous)