IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Migration SGBD Discussion :

Migration de données pour être centralisées


Sujet :

Migration SGBD

  1. #1
    Membre régulier
    Inscrit en
    décembre 2006
    Messages
    256
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 256
    Points : 70
    Points
    70
    Par défaut 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

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 689
    Points : 49 027
    Points
    49 027
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    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) ?
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  4. #4
    Membre régulier
    Inscrit en
    décembre 2006
    Messages
    256
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 256
    Points : 70
    Points
    70
    Par défaut
    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...

  5. #5
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    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...
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  6. #6
    Membre régulier
    Inscrit en
    décembre 2006
    Messages
    256
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 256
    Points : 70
    Points
    70
    Par défaut
    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.

  7. #7
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    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.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  8. #8
    Membre régulier
    Inscrit en
    décembre 2006
    Messages
    256
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 256
    Points : 70
    Points
    70
    Par défaut
    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.

  9. #9
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    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.).
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  10. #10
    Membre régulier
    Inscrit en
    décembre 2006
    Messages
    256
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 256
    Points : 70
    Points
    70
    Par défaut
    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

  11. #11
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    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.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  12. #12
    Membre régulier
    Inscrit en
    décembre 2006
    Messages
    256
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 256
    Points : 70
    Points
    70
    Par défaut
    Ok merci pour les conseils

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Aide pour la migration de donnée d'Access vers Eprints
    Par Lymnidol dans le forum Modélisation
    Réponses: 1
    Dernier message: 10/06/2012, 19h30
  2. Réponses: 1
    Dernier message: 04/02/2012, 14h37
  3. Réponses: 5
    Dernier message: 11/02/2011, 21h37
  4. Importation de données pour migration sur Access 2007
    Par julius26 dans le forum Modélisation
    Réponses: 4
    Dernier message: 30/03/2009, 18h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo