Migration de données pour être centralisées

Bonjour,

Dans le cadre d'un projet de centralisation, nous aurions besoin de centraliser les 100 bases de données SQL Server 2005 existantes en une seule base de données.
La nouvelle base de données centralisée n'aura pas le même MCD que les 100 bases actuelles.

Cette centralisation a pour but premier d'avoir qu'un seul "fichier" client commun à tout le monde.
Nous allons donc devoir analyser tous les clients existants en doublon afin de repartir sur une base cliente propre.

Quel est à votre avis la meilleur solution sachant que nous devons garder un historique de factures, d'interventions durant 10 ans et que ces données seront aussi migrées vers la nouvelle base de données.


Merci d'avance

Cordialement

Puisque vous êtes dans le cas de MS SQL Server, plusieurs solutions s'offrent à vous (du plus fiable/simple au plus complexe/moins fiable) :
1) l'utilisation de la réplication de données, soit en mode transactionnelle, snapshot, pier-to-pier ou encore de fusion
2) l'utilisation de Service Broker destiné aux bases de données distribuées (envoi de message de données XML de manière asynchrone et transactionné)
3) l'utilisation de SSIS, l'ETL intégér de MS SQL Server
4) les outils CHANGE TRACKING et CDC
5) l'utilisation de BCP.exe avec du code Transact SQL et des commandes systèmes
6) la mise en œuvre de déclencheurs + code divers

A +

SQLPro a bien résumé les moyens qui s'offrent pour transférer les données.

Au niveau de la modélisation, qu'as-tu choisi ? Quel sera l'usage de cette base centrale : essentiellement transactionnel (OLTP) ou à des fins de reporting (OLAP) ?

Le but de cette base centrale est de supprimer déjà les 100 bases SQL actuelles, avoir une base cliente commun à tous les utilisateurs.

L'usage de cette base centrale restera le même que les 100 bases SQL, c'est à dire de la facturation, création d'intervention, de devis, statistiques etc...

Le plus difficile à mon avis, est de purger les fichiers clients, car nous avons de noubreux doublons, voir des clients créér n'importe comment etc...

Ok, perso pour avoir réalisé quelques migrations, je te conseille d'utiliser un ETL (SSIS). C'est plus simple à manipuler et à débugguer, et plus visuel pour mettre en place les règles, notamment de dédoublonnage, et les règles en cas d'erreur...

Je vais regarder du côté de SSIS.

Par contre, en discutant avec des développeurs ayant eux aussi déjà effectué des migrations pour la refonte de logiciel, certains le faisait en 2 étapes :

1ere étape :
garder la base de données actuelle mais en développant le nouveau logiciel

2eme étape :
re-développer les process métier au fur et à mesure et en modifiant en même temps la base de données.

Oui il y a plusieurs façons de procéder : soit avec un "big bang" (on change tout en même temps, les bases + l'appli), soit de manière progressive comme tu l'as écrit dans ton post précédent.

Le choix de la méthode doit se baser sur plein de facteurs (risques, temps, budget, resources...). Chacune offre des avantages et des inconvénients.

Je regardais du côté de SSIS, il n'existe pas avec SQL Server 2005 Express et je ne crois pas qu'on ai accès à toutes les fonctionnalités avec une version Workgroup.

Effectivement, il faut au minimum la version Standard de SQL Server 2005... Il y a d'autres ETL qui existent sur le marché, mais personnellement je n'ai jamais bossé avec (Talend, Informatica, etc.).

Par contre, j'avais une question concernant la centralisation des comptes client.

Admettons que j'ai 4 clients Total avec 4 codes client différents, lors de la centralisation nous allons garder un seul compte client Total avec un nouveau code client.

Pour garder l'historique des factures de 4 clients Total, est il mieux de créer une table de relation avec le nouveau code client pour lequel appartient les 4 anciens code client ?

Merci

Difficile de te répondre, la question qu'il faut se poser c'est y'a-t-il un intérêt à conserver l'ancien code client ? Seul ton client (ou ta connaissance de leur besoin) pourra y répondre...

S'il faut le conserver, tu peux utiliser comme tu le suggères une table dédiée à stocker cette info (en gros, 2 colonnes : une pour le nouveau code, et une pour l'ancien, donc au final pour Total tu auras 4 lignes).

Quelle que soit la décision prise, je te conseille quand même de conserver dans un coin (genre un fichier Excel ou autre), un mapping entre les anciens codes et les nouveaux, ça peut toujours servir...

Pour l'anecdote, sur ma première migration, j'avais fait l'erreur de ne pas conserver de trace de l'ancienne clef. Une fois la migration terminée, on s'est aperçus qu'une petite partie des données n'était pas correcte. Résultat, pour remettre d'aplomb, même si ça ne concernait qu'une toute partie des données, on a mis un peu plus d'un mois à retomber sur nos pieds, à coup de mappings manuels, etc. Alors que si on avait gardé quelque part un mapping de l'ancienne clef et de la nouvelle, ça nous aurait pris quelques heures tout au plus.

Ok merci pour les conseils :)