Ça n'est pas un travail facile, car il faut dès fois faire du E-Archéologie, souvent on doit choisir des données par défaut pour les extensions fonctionnelles et les batch de reprises sont une source d'intérogation technique et fonctionnelle.

Sur mon dernier projet, nous avons choisi de définir un schéma de base de donnée le plus stricte possible, afin de pouvoir garantir au mieux la cohérence des données. Nous avons utilisé des Validateurs Hibernate pour remonter des messages utilisateurs clairs et localisés.

Placer des contraintes fortes du côté de la base de donnée garantie une haute cohérence des données, mais cela pose quelques problèmes techniques et fonctionnels pour la reprise des données.

Données existantes incohérentes

Premièrement, l'existant est souvent incohérent. La mauvaise nouvelle c'est qu'il va y avoir du travail en plus. Il va falloir demander au MOA de s'investir dans un travail en binome avec un MOE pour orienter une correction des données existantes afin de rendre le système cohérent. La bonne nouvelle est que ce travail va permettre au MOA de détecter précisément les erreurs qu'il se traine depuis dès fois plusieurs années (voir dizaine d'années dans le cas de mon projet :)

La reprise demande des états intermédiaires

Les Pojos de la nouvelle application ne permettent pas une reprise des données directe, à cause des contraintes d'unicité ou de non-nullités. La solution que nous avons choisi est de passer par une pseudo BDD intermédiaire qui ne possède pas de contraintes.

Nous avons utilisé Lucene d'Apache, qui stock les Pojos en les sérialisant dans des fichiers. Cet outil est très puissant, car flexible, avec possibilité de création d'index.

Nous avons donc fait un export des données existantes au format CSV. Nous avons lu les données avec un batch maison écrit en Java et stocké les objets dans Lucene, le temps de les remplir correctement avec des règles de reprise de données. Une fois que les objets sont cohérent dans Lucene, il suffit de les persister dans la base de données réelle.