Discussion :

[pcaboche]

Bonjour,

Je vais essayer d’être assez précis dans la description du problème qui me préoccuppe.


Contexte:
Dans l’entreprise où je travaille, une application a été développée et est en production depuis plusieurs années. Actuellement, une nouvelle version est en cours de développement (et c’est justement sur cette version que je travaille).

Les deux versions (celle en prod et celle en dev) vont donc devoir cohabiter pendant un certain temps (1 à 2 ans). La version en prod utilise une base de données SQL Server 2000, celle en dev utilise SQL Server 2005. De plus, le modèle de données a évolué entre les deux versions et la structure de la base de données comporte des différences.

Ce qui est demandé, c’est de pouvoir utiliser conjointement les deux versions de l’application et que les modifications de données sur la base SQL Server 2000 (utilisée par l’application actuelle) soient automatiquement répercutées dans la base SQL Server 2005 (utilisée par la nouvelle application), avec les transformations nécessaires.



Recherches de solution :
Nous nous sommes d’abord orientés vers une réplication transactionnelle. Cependant la réplication seule n’effectue pas la transformation des données.

J’ai effectué quelques recherches sur les outils Microsoft disponibles pour répondre au besoin et je suis d’abord tombé sur DTS (Data Transformation Services). Ne connaissant pas DTS, je me suis documenté mais je ne sais pas si DTS est vraiment la solution adaptée au problème.

D’après ce que j’ai vu, les solutions en matière de synchronisation de bases de données ont énormément évolué entre SQL Server 2000 et 2005. Outre le fait que DTS s’est amélioré, j’ai pu lire qu’Integration Services, apparu avec SQL Server 2005, venait remplacer cette technologie.

Aussi, j’ai besoin de vos lumières car je suis un peu perdu entre les différentes solutions disponibles.



Pour résumer, je cherche la réponse aux questions suivantes :
- Vers quelle solution m’orienter ? Integration Services, DTS, ou autre ?
- Ai-je bien saisi l’intérêt des différentes technologies sus-citées ou est-ce que quelque chose m’échappe ?

Rappel des besoins :
- répercuter les modifications de données d’une base SQL Server 2000 dans la base SQL Server 2005
- la synchronisation comporte une transformation des données
- la synchronisation est unidirectionnelle (SQL Server 2000 -> 2005)
- la synchronisation doit être automatique


D’avance merci pour votre aide précieuse.

Pierre

[rudib]

Tant que tu n'as pas de modification de structure à répercuter de façon automatique, SSIS est le bon choix. Il est beaucoup plus puissant que DTS. Peut-être plus complexe, mais l'apprentissage vaut le coup.

[pcaboche]

Tant que tu n'as pas de modification de structure à répercuter de façon automatique, SSIS est le bon choix.

Merci, ça me rassure (j'avais peur de me lancer dans l'apprentissage d'un outil qui ne nous servirait pas... ).

SSIS est la solution que j'étais en train d'explorer (pour l'instant, création de packages) et ça a l'air assez puissant. De plus, SSIS pourra éventuellement nous resservir plus tard.

Maintenant, ce que je voudrais savoir, c'est s'il est facile de déployer les packages pour planifier les réplications ou les rendre automatiques ?

En tous cas, merci rudib pour ta réponse.

[rudib]

La planifiaction est très aisée. Tu peux planifier avec l'agent SQL, ou avec tout planificateur de tâche, comme celui de Windows.

Si tu lis l'anglais, il y a un bon bouquin sur le sujet chez Wrox (professional SQL Server Integration Services...)

[pcaboche]

Bonjour,

J'ai défini le traitement de transformation de données avec SSIS et maintenant il me reste à trouver comment effectuer cette conversion de manière automatique (à la manière d'une réplication transactionnelle) et je vais plancher sur le sujet.

Concernant le problème de fond ("quelle technologie utiliser pour le tranfert de données ?"), la réponse me satisfait et je vais donc mettre le sujet en "Résolu".


Pour ceux qui tomberaient sur ce sujet par hasard (comprenez:"après une recherche Google"), voici mes premières impressions concernant SSIS:

• c'est très visuel: les traitements effectués apparaissent sous forme de graphiques éditables. Cela donne une bonne vue d'ensemble de ce que l'application fait et facilite la communication avec les collègues. Cela facilite aussi la prise en main de l'outil (il y a encore 5 jours, je ne savais même pas ce qu'était SSIS !)
• les erreurs apparaissent clairement: si on a une incohérence sur un traitement (ex: mauvais type de colonne), une croix rouge (ou un triangle jaune) apparait sur le composant concerné
• débuggage facilité: après exécution (touche F5) les traitements ayant échoué apparaissent en rouge et un panneau détaille les résultats d'exécution
• non limité aux seuls outils Microsoft: SSIS permet de rapatrier les données depuis des sources diverses, y compris bon nombre de bases de données via OLE DB
• permet de faire des choses puissantes, notamment en matière de Data Warehousing (un matière que je ne connais pas encore très bien)

Voilà pour mes premières impressions, il me reste maintenant à découvrir l'outil plus en profondeur.

Si tu lis l'anglais, il y a un bon bouquin sur le sujet chez Wrox (professional SQL Server Integration Services...)

Il faudra que je regarde ça. Ca peut valoir le coup que je me l'achète.

[rudib]

Le livre de Wrox couvre un peu toutes les fonctionnalités de SSIS, mais pas tous les détails, c'est trop complexe. Par exemple les tâches d'Analysis Services ne sont qu'effleurées. Si tu veux tout savoir en détail sur le produit, il restera encore des choses à piocher.

[pcaboche]

Et bien en fait, pour l'instant, on va partir sur une autre solution qui pourrait répondre au besoin immédiat, tout en se documentant un peu plus sur SSIS.

Encore merci pour les références.