# Data versioning

## Sommaire

- [Introduction](#introduction)
- [Motivation](#motivation)
- [Guide-level explanation](#guide-level-explanation)
- [Reference-level explanation](#reference-level-explanation)
- [Justification et alternatives](#justification-et-alternatives)
- [Impacts si la situation reste ainsi](#impacts-si-la-situation-reste-ainsi)
- [Etat de l'art](#etat-de-l'art)
- [Questions non résolues](#questions-non-resolues)
- [Possibilités futures](#possibilites-futures)

## Introduction

Cette RFC porte sur l'historisation des données au sein d'une base de donnée relationnelle.

## Motivation

Les raisons qui nous poussent à faire un document sur le sujet de l'historisation au sein d'une base de données relationnelle sont :

- Avoir une traçabilité de l'évolution de la donnée dans le temps.
- Savoir qui a fait évoluer la donnée (Audit Log).
- Revenir à une sauvegarde antérieure de la donnée.
- Analyser l'évolution des données pour :
- Détecter des anomalies
- Réduire les risques
- Améliorer la qualité des données
- Support de la gouvernance des données

## Guide-level explanation

### Exemple du nouveau format de données

**Afin de mieux comprendre le avant/après de nos données versionnés, voici un exemple simplifié des données d'un projet :**

Avant :

| Identifiant | Nom | En production ? | Crée le | Modifié le |
| ----------- | --- | --------------- | ------ | --------------- |
| 1 | Mon-projet-production | Oui | 01/01/2024 10:00:00 | 10/10/2024 16:30:00 |

Questions en suspend face à ce tableau :
*Qui a crée ce projet ?
Qu'est-ce qui a été modifié, quand et à quel moment ?
Combien de modifications ont été effectuées entre le 01/01/2024 et le 10/10/2024 ?
...*

Après :

| Identifiant | Nom | En production ? | Crée le | Modifié le |
| ----------- | --- | --------------- | ------ | --------------- |
| 1 | Mon-projet-production | Oui | 01/01/2024 10:00:00 | 10/10/2024 16:30:00 |
| 1 | Mon-projet-test | Non | 01/01/2024 10:00:00 | 15/10/2024 16:30:00 |
| 1 | Mon-projet-prod | Oui | 01/01/2024 10:00:00 | 20/10/2024 16:30:00 |

*La date de création reste la même afin d'avoir un comparatif au fil du temps entre la création et la modification.
Le projet reste reconnaissable grâce à son identifiant unique.*

### Fonctionnalités applicatives

Dans les applications **Molink** et **SAO**, les utilisateurs auront la possibilité de visualiser l'historique de modifications de :
- Son organisation (nom, description)
- Ses projets (nom, description, statut de production)
- Ses déclarants (Matricule, griffe, métadonnées, liens externes ...)
- Ses avis de décès (informations relatives au défunt, avis de décès, cérémonie ...)
- Ses commandes (type de l'avis, support de diffusions, composition ...)

#### Exemple visuel:

### Avantages utilisateurs

Avec cette historisation, il sera possible pour les utilisateurs de mieux comprendre l'évolution de leurs données, d'identifier d'eux-même de potentielles anomalies et de faire de la surveillance.

**Le but est de rendre le pouvoir au métier.**

## Reference-level explanation

--

## Justification et alternatives

-- pourquoi on a choisie cette solution

### Autres conceptions envisagées

#### Versionning simple

Avoir une colonne `increment integer version` en integer que l'on incrémente dans la table courante.

##### Avantages

- Facile à implémenter

##### Inconvénients

- Gestion des relations.
Exemple : Pour une relation ManyToOne `projet_déclarants`. La modification du projet entraînera une nouvelle ligne dans la BDD et donc mettra à jour les relations `projet_déclarants`.
- Augmentation de la taille de la base de données.
Avec des tables qui ont déjà >1M lignes (avis), l'ajout de l'historisation peut multiplier par 20 le nombre de lignes, ce qui pose problème d'un point de vue indexation. Le parcours de la table avis serait excessivement long : On ne souhaite pas parcourir une table qui contient les lignes d'historisation
- La plupart des requêtes effectuées le sont sur la version la plus récente du document.

#### Table d'historisation

Avoir une table d'historisation pour l'ensemble des tables de la base de données (Exemple : table `historization`)

##### Avantages

- Implémentation facile avec des triggers SQL.
- Garde les tables principales inchangées.

##### Inconvénients

- Table avec des millions de lignes, pose soucis lors du parcours de lignes en terme de performances.

#### Tables d'historisation

Chaque table en base de données possède sa propre table d'historisation. (Exemple : table `projects` et `historization_projects`).

Pour savoir dans quelle version est la donnée, chaque donnée aura une nouvelle colonne `version`.

##### Avantages

- Implémentation facile avec des triggers SQL.
- Permet de charger l'historique seulement au besoin.

##### Inconvénients

- A définir

## Impacts si la situation reste ainsi

Si la situation reste ainsi, cela n'aura pas de conséquence dans l'évolution des fonctionnalitées de Molink.

Cependant, il ne sera pas possible aux utilisateur de revenir très rapidement a un état stable de la donnée.

Dans certain cas, l'équipe technique Molink devra intervenir pour effectuer un retour en arrière de la donnée.

Les utilisateurs auront un visuel boîte noire sur l'évolution de leurs données.

## Etat de l'art

MangoDB opte pour le fait d'avoir une table de révision par table : [Lien vers l'article](https://www.mongodb.com/blog/post/building-with-patterns-the-document-versioning-pattern)

## Questions non résolues

Aucune au moment de la rédaction du document

## Possibilités futures

Aucune au moment de la rédaction du document