Discussion :

[pline]

Bonjour,

Je suis actuellement sous Sybase 11.5.3 et je pense migrer vers SQL SERVER. Avant que Microsoft me présente tout l'intérêt de mon choix, j'aimerai avoir quelques retour d'expérience (surtout les négatives).
A savoir que j'ai des développeurs JAVA et PHP et que nous pensons remplacer également notre ETL ODI par celui fourni avec SLQ-SERVER.

Merci.

[Ptit_Dje]

Concernant le SGBD, je n'ai pas vraiment de point de comparaison à fournir.

Par contre, concernant l'ETL, je me demande pour quelle raison vous souhaitez changer... ODI fonctionne très bien avec SQL Server, et est pour moi un ETL bien plus intéressant que SSIS !
Il est vrai qu'il est un peu lourd pour des petits développements, par contre il permet une flexibilité assez impressionnante avec la séparation des schemas physiques/logiques et l'utilisation des contextes.
De plus, les informations sur les métadonnées sont vraiment intéressantes.

[Waldar]

J'ai une petite expérience de deux ans en développement / TMA sur SSIS (pas à plein temps).

Je ne connais pas ODI, mais l'outil de Microsoft est encore beaucoup trop limité. Enfin oui et non.
On peut potentiellement tout faire avec, mais il y a d'énormes points faibles, en vrac :

• les écritures d'update
• pas de suivi du changement du modèle (rajoutez une colonne dans une table, il faudra avoir noté tous les projets / dataflow utilisant cette table pour faire l'impact).
• lourdeur de l'interface à partir d'un certain point (si votre PC n'est pas de dernière génération, celà peut prendre 10 minutes à ouvrir un projet d'une dizaine de méga), 2 Go de RAM sont vraiment nécessaires
• interface MS très complète, mais les options importantes sont noyées dans des options inintéressantes
• des performances volontairement lamentables avec Oracle (il faut acheter un connecteur tiers)
• le suivi des exécutions, notamment des erreurs est mal pensé (champ tronqué au moment où le message d'erreur commence à apparaître)

Evidement il a un énorme point fort, c'est d'être inclu avec SQL Server.

[mikedavem]

Je n'ai pas autant d'expérience que Waldar sur le sujet mais je le rejoins sur certains points qu'il a cité :

Il est vrai que BIDS est assez consommateur de ressources dès lors que l'on commence à avoir un projet important.

De plus, il est vrai que par rapport à 2000, le suivi des erreurs est beaucoup plus complet et ergonomique mais le tronquage des messages d'erreur empêche un suivi facile ... dommage

Quelqu'un a une expérience concernant la version 2008 ?

++

[Ptit_Dje]

J'ai une petite expérience sur 2008.
Pour ce que j'en ai retenu, c'est que ca n'a pas beaucoup changé depuis 2005... Je n'ai peut être pas eu besoin des nouveautés aussi.

Pour en revenir à ODI, voici ce que j'avais posté sur le forum ETL:

Bonjour,

Je peux partager mon point de vue sur ODI:
Les + pour moi sont:
- Séparation des schémas physiques/logiques -> Pratique lorsque l'on déplace des bases de données, il suffit de recréer le lien et les packages sont supposés refonctionner, minimum d'effort.
- Utilisation de contextes, permettant de créer un lien entre les schémas physique et logiques, ce qui permet un deploiment/testing d'un environnement à l'autre facilement.
- Utilisation des KM prédéfinis, gérant toutes sortes de tâches. Possibilité de les customiser comme l'on veut.
- Fonctions de substitutions très pratiques pour faire du code générique.
- Utilisation d'un master repository et d'un à plusieurs work repository.
- L'opérateur donne des informations claires sur ce qui se passe dans les packages.
- Utilisation des agents afin de faire travailler le serveur que l'on souhaite, en fonction des packages.
- Possibilité de customisation de la sécurité assez poussée.
- Possibilité d'utilisation de beaucoup de technologies différentes (java, python...) pour le scripting.
- Possibilité de bien documenter les méta-données.
- Gestion des erreurs facile

Les -:
- Parfois un peu lourd à utiliser pour des petits packages.
- Prise en main pas évidente au début.
- (je sais pas si toujours d'actualité) Problèmes de lock lorsque l'on veut modifier un package stocké, au niveau du repository, entrainant des freezes de l'écran de développement.

Personnellement, j'ai beaucoup apprécié cet ETL.