Mon département est spécialisé dans la conversion des données clients dans notre schéma de base de données afin qu'ils puissent utiliser notre logiciel.

Actuellement, nous avons des applications C # qui prennent un IDataReader(99% du temps, c’est un SqlDataReader), effectuent quelques nettoyages et mappages, l’insèrent dans un DataRowobjet, puis utilisent un SqlBulkCopypour l’insérer dans notre base de données.

Parfois (surtout lorsque la base de données source contient des images en tant varbinaryqu’objets), ce processus peut s’embourber avec un transfert SQL du serveur vers l’application pour ensuite faire demi-tour et revenir au serveur.

Je pense que si nous réécrivions certaines des conversions sous forme de packages SSIS, cela pourrait accélérer beaucoup les choses. Cependant, le plus gros obstacle que je rencontre encore, c’est lorsque mon patron, dans la mode Not Invented Here , recule et dit: «Que se passe-t-il si Microsoft supprime la prise en charge de SSIS? Nous aurons tout ce code obsolète et nous serons foutus."

Ce n'est pas la première fois que je frappe un "Et si on supprime cette fonctionnalité ...?" réponse de mon patron. Je n'ai pas le temps d'écrire la conversion à l'ancienne, de m'enseigner moi-même SSIS et de l'écrire aussi avec la nouvelle façon de démontrer / tester les avantages (aucun d'entre nous n'a utilisé SSIS, il y aurait donc une période où apprendre à l'utiliser).

Que dois-je faire dans cette situation? Arrêtez de pousser la nouvelle technologie? Attendre qu’il quitte le département (je suis la deuxième personne la plus importante du département après lui, mais il se pourrait que des années se soient écoulées avant qu’il quitte / prenne sa retraite)? Trouver une nouvelle façon de lui faire cesser d'avoir peur des outils tiers?

Je vais essayer de résoudre ce problème du point de vue de la direction, mais n'oubliez pas que je ne connais pas tous les détails. Je vais résumer ce que je vois:

1. Le développeur de niveau intermédiaire, nous l'appellerons "Scott", recommande de réécrire le code existant dans SSIS afin d'améliorer les performances du processus important ProcessA.
2. ProcessA se comporte actuellement dans un état de fonctionnement sans aucun problème majeur connu.
3. ProcessA est écrit avec des outils propriétaires utilisant des connaissances communes ou potentiellement tribales à maintenir.
4. La recommandation de réécrire nécessitera de nouveaux outils.
5. Le personnel actuel n'a aucune expérience / connaissance documentée des nouveaux outils.
6. Les nouveaux outils sont des substituts relativement récents aux outils plus anciens, et la prise en charge de ces outils peut changer de manière raisonnable au cours des quatre trimestres d'activité.

De ce point de vue, tout ce que je vois, c’est une grosse dépense d’argent de la part de l’entreprise pour améliorer un processus qui ne soit pas interrompu . D'un point de vue technique, je peux voir l'appel, mais quand vous y tenez, il ne sert à rien de faire ce changement. Si vous avez du personnel avec une expérience documentée avec SSIS et des points de repère pour montrer une amélioration considérable de ce processus (gardez à l'esprit, une amélioration massive DOIT être équivalent à $$$), le résultat pourrait être un peu différent. Dans l'état actuel des choses, cependant, je suis d'accord avec la direction (quelque part, un arbre vient de mourir).

Si vous souhaitez encourager l'adoption de SSIS et éventuellement mener à ce refactor, vous devez acquérir cette expérience et cette formation dans le cadre de projets plus petits et moins importants. Fournissez des points de repère et un support pour SSIS, et assurez-vous que toute l'infrastructure et le support sont en place avant même que la direction n'envisage même d'effectuer le changement. Une fois l’outil utilisé ailleurs, les membres de l’équipe expérimentés dans son utilisation et le facteur de "confort" de l’entreprise, selon lequel le support ne changera pas et ne déracinera pas tout, vous aurez plus de chances d’influencer quelqu'un de votre point de vue. Sans cela, vous vous trompez d'arbre avec cet argument.

Aussi stupide que cela puisse paraître, parfois, le "meilleur" moyen n'est pas le meilleur.

Edit: En réponse à certaines mises à jour de la question, je publierai une légère modification à ma réponse.

Si le processus connaît une détresse quelconque, sa réécriture restera une entreprise coûteuse. Vous voudrez peut-être envisager le coût de la mise au point du code existant par rapport à la réécriture du package. Considérez les impacts non seulement sur les logiciels, mais sur tous les processus d'interface humaine. Quand on essaie d'obtenir l'adhésion de la direction à une réécriture, cela revient toujours à l'argent. À moins que vous ne puissiez démontrer que la détresse actuelle coûte de l'argent maintenant ou va s'aggraver dans son ensemble, la direction n'en verra toujours pas l'avantage. Ce coût peut ne pas être nécessairement de nature financière. Si le ralentissement compromet un système causant des temps d'arrêt, introduit des vecteurs d'intrusion ou un autre symptôme "difficile à quantifier", vous devrez peut-être trouver un moyen de traduire ce problème en équivalent de risque monétaire. Un vecteur d'intrusion, par exemple, peut conduire à une intrusion pouvant entraîner la perte, le vol ou la corruption de données. L'entreprise pourrait perdre sa réputation ou échouer lors d'un audit de sécurité nécessaire. La clé est de faire en sorte que le gestionnaire en question reconnaisse les avantages quantifiables du changement.

Casser des choses est une compétence

J'ai travaillé dans beaucoup trop d'endroits qui ont adopté l'argument "si ce n'est pas rompu" au point qu'ils ne parviennent pas à innover et lorsqu'ils sont finalement contraints d'innover, ils réagissent en changeant tout . Tout simplement parce qu'ils n'ont pas l'expérience de casser des choses .

Il faut de la maturité, des compétences et de l'expérience pour casser des choses.

Les équipes de développement qui jouent toujours en sécurité sont les plus faciles à surpasser pour un concurrent. Seules les équipes qui ont échoué, commis des erreurs et des problèmes peuvent véritablement réaliser des évaluations de risque honnêtes.

Garder le statu quo

Bien que ce soit vrai, le système actuel répond aux exigences commerciales actuelles. Ce n'est pas vrai pour les futurs changements imprévus à ces exigences. Comme le dit le vieux proverbe, "la fortune préfère le préparé".

Cette question n'a rien à voir avec SQL ou les performances. Il s'agit de poser la question "Y a-t-il un meilleur moyen?" et ne pas avoir peur d'essayer une alternative.

Votre patron souffre d'un cas de maintien du statu quo .

Les Mayas

Rien ne fonctionne vraiment parfaitement.

Les Mayas continuaient à faire pousser leur nourriture du côté des montagnes. Jusqu'à ce que tous les nutriments aient été emportés, et ils n'avaient aucun moyen de nourrir leur peuple. Ils ont continué à faire les choses de la même manière jusqu'à ce qu'il soit trop tard.

En supposant que vous aurez le temps de résoudre un problème lorsque celui-ci se présente, c'est une erreur.

Que faire?

Votre patron souffre d'un cas de conditionnement. Les personnes qui acceptent le statu quo le font souvent, car elles n’ont pas la capacité de prendre des décisions difficiles. Lorsqu'ils sont confrontés à un défi, ils auront tendance à choisir l'option la plus proche de ce qu'ils connaissent.

La peur pour lui est une grande motivation. La peur de l'inconnu ou des conditions changeantes ébranle sa perspective de ce qu'est le statu quo. Il aura tendance à essayer de rétablir les conditions normales le plus rapidement possible.

Vous devez présenter les idées de manière non conflictuelle. Essayez de trouver un terrain d’entente entre ce que vous voudriez faire et ce qui est déjà le statu quo. Présentez des arguments qui réduisent sa peur du changement et rassurez-vous sur le fait que vous souhaitez effectuer une tâche qui ne provoquera pas de changement significatif.

Faire des pas de bébé

Il serait préférable de proposer des modifications qui déplacent le projet dans la direction souhaitée, mais via de petits projets incrémentiels. Plutôt que de frapper votre patron avec la grande question sur le soutien à SSIS. Proposez de créer une couche de séparation dans le code qui vous permettrait de greffer des méthodes "alternatives" pour le traitement des tables avec des pièces jointes volumineuses. Vous pouvez ensuite progresser pour recommander SSIS avec tous les prérequis déjà ajoutés au projet. Cela réduit le risque que votre patron envisage en acceptant le changement.

Ça prend du temps

D'après mon expérience, les preneurs de risques font avancer un projet et les tenants du statu quo sont comme un mur de briques. La persistance est votre seule option pour abattre leurs barrières. Attendez-vous à continuer d'entendre non à vos demandes.

Quand vient le temps d'innover. Votre patron se tournera rapidement vers vous, car vous faites preuve de témérité face au changement. Quelque chose qu'un statu quo cherchera et vous serez récompensé pour vos efforts. Même si aucune de vos demandes précédentes n'a été acceptée. Vous deviendrez rapidement un atout irremplaçable dans une entreprise confrontée à un changement inconditionnel.

Je pense que si nous réécrivions certaines des conversions sous forme de packages SSIS, cela pourrait accélérer beaucoup les choses. Cependant, le plus gros obstacle que je rencontre encore, c’est lorsque mon patron, dans la mode Not Invented Here, recule et dit: «Que se passe-t-il si Microsoft supprime la prise en charge de SSIS? Nous aurons tout ce code obsolète et nous serons foutus."

À mon avis, le scepticisme à propos de SSIS est valable.

• Les développeurs chevronnés détestent les boîtes noires et il y a beaucoup de magie dans un package SSIS.
• La prise en charge du contrôle de source pour les packages SSIS fait cruellement défaut. Diviser et fusionner des fichiers SSIS dtsx peut être un cauchemar si vos packages dtsx ne sont pas suffisamment modulaires.
  • En revanche, les applications de la console C # sont très transparentes. Vous pouvez toujours suivre le code pour déterminer ce qui ne va pas.

En outre, considérez que votre patron est sur le crochet si quelque chose ne va pas.

• Par conséquent, il a le droit d'avoir l'opinion dominante / unique en la matière.

Je n'ai pas le temps d'écrire la conversion à l'ancienne, de m'enseigner moi-même SSIS et de l'écrire aussi avec la nouvelle façon de démontrer / tester les avantages (aucun d'entre nous n'a utilisé SSIS, il y aurait donc une période où apprendre à l'utiliser).

Que dois-je faire dans cette situation? Arrêtez de pousser la nouvelle technologie? Attendre qu’il quitte le département (je suis la deuxième personne la plus importante du département après lui, mais il se pourrait que des années se soient écoulées avant qu’il quitte / prenne sa retraite)? Trouver une nouvelle façon de lui faire cesser d'avoir peur des outils tiers?

Je vous recommande d'apprendre suffisamment SSIS pour pouvoir en démontrer les avantages.

Et si, après votre auto-apprentissage, vous trouvez que SSIS offre des avantages significatifs par rapport à l'approche plus "traditionnelle" et que vous ne pouvez toujours pas convaincre votre patron de changer de cap, je vous recommande de trouver un autre emploi dans lequel vous pourrez: utiliser SSIS.

La réponse à laquelle vous répondez presque toujours de la plupart des types de gestionnaires ressemble à quelque chose comme:

"Ca ne vaut pas la peine, ça marche maintenant, et ça va prendre du temps pour changer."

Et en général, cela est valable. Cependant, cet argument n'est pas toujours valable, car le problème central concernant le syndrome "Pas inventé ici" n'est pas de savoir si les choses fonctionnent ou non, mais que la technologie est inutilement réécrite , gaspille les heures de travail de la société et nuit à une valeur substantielle. à partir du produit livré.

Vous devez déterminer si la fonction Not Invented Here (Pas inventé ici) a effectivement lieu avant de décider quoi faire. La technologie interne peut avoir été écrite pour une raison .

Signes que le Tech est réécrit pour une raison:

• La technologie que vous vendez est également le produit . Si vous êtes un fournisseur de base de données, utiliser du code MySQL, quelle que soit la durée de sauvegarde, est une idée dangereuse pour de nombreuses raisons.
• La technologie interne est bien entretenue et corrige efficacement les faiblesses de la solution standard, tout en offrant des fonctionnalités de base comparables.
• La technologie améliore la productivité de l’ensemble de l’équipe de développement et permet aux nouveaux développeurs de savoir pourquoi elle est utilisée.
• Il existe d'autres exemples où l'entreprise a adopté avec succès d' autres technologies externes .
• Votre entreprise serait immédiatement et sérieusement touchée si la solution OTS était abandonnée ou en panne.
• L’entreprise est si grande qu’elle dispose des ressources nécessaires pour écrire des outils de haute qualité à faible coût (par exemple, Google peut éventuellement écrire une base de données coûtant moins d’une licence MS SQL de 1 000 dollars par siège).

En d’autres termes, l’équipe comprend les inconvénients de la résolution de problèmes déjà résolus, mais fait judicieusement des exceptions lorsque cela s’avère logique du point de vue des entreprises.

Les signes de "pas inventé ici":

• On dirait que tout est interne et qu'il y a des excuses pour tout: "euh, c'était trop lent", "euh, c'est Microsoft, on déteste Microsoft", "euh, ça a l'air vraiment difficile à utiliser", etc.
• Dans les cas où une technologie externe est utilisée, vous entendez "Ouais, eh bien ça pue et nous prévoyons d’écrire notre propre à terme ".
• Les propriétaires de ces composants n'ont pas d'autres emplois sur lesquels ils sont capables de travailler.
• La plupart des nouveaux développeurs arrivent avec un ensemble de compétences largement acceptées, mais il leur faut beaucoup de temps pour s’adapter à l’outillage interne.
• Après une analyse minutieuse, il devient pertinent de passer de la solution OTS à une solution personnalisée ou à une autre solution OTS dans " Que se passe- t-il si elle est abandonnée!" Ce scénario aurait un impact minime sur les entreprises . Par exemple, si elles String.Join()étaient supprimées du .NET Framework, une nouvelle implémentation dans une StringJoin()méthode personnalisée serait triviale.

En d'autres termes, NIH est le modèle qui consiste à ne pas rester objectif et réaliste dans les cas où une technologie externe est utilisée à la place de son propre code.

Lorsque la technologie est réécrite pour une raison quelconque, vos supérieurs doivent féliciter et apprécier vos préoccupations. La mise en œuvre de la technologie aurait dû être une décision prudente, et le réexamen de la décision est parfois bénéfique pour l'entreprise. Les choses changent avec le temps et vous pouvez avoir un argument valable. Si vous pouvez fournir des chiffres sur le temps perdu dans le passé, les coûts projetés de la commutation et d'autres informations, vous pouvez (en théorie) justifier le changement.

Comprenez que, compte tenu de votre expérience, ils pourraient ne pas être d'accord avec vos chiffres, mais peu importe, ils devraient au moins vous entendre. Cela peut prendre du temps pour gagner le respect.

Si la conversation ne peut même pas être évoquée, même si vous êtes poli, cela pourrait simplement être "Pas inventé ici". Dans ce cas, il s'agit probablement d'un problème de personnalité ou politique que vous ne pouvez probablement pas résoudre facilement. Travailler dans un environnement qui est lourdement enlisé par une réinvention constante est toxique pour les développeurs et l’entreprise. Courir.

(Remarque: dans la plupart des entreprises, il existe toujours un élément des NIH, mais il est à un niveau tolérable et à condition de revoir régulièrement son code et ses pratiques. À long terme, nous en sommes tous coupables, mais cela ne devient jamais un problème.)

Eh bien, tout est une question d'analyse coûts / avantages.

Que gagnez-vous en le réécrivant sur SSIS? La vitesse? Est-ce que ça importe? Si c’est un processus qui est exécuté dans une interface graphique et fait perdre du temps à tout le monde, alors oui, c’est probablement une bonne idée de l’accélérer, car l’argent dépensé pour le changer sera récupéré par un client plus heureux ou un employé interne qui fait son travail au lieu de en attente du logiciel. Mais si c'est un groupe de nuit qui commence à 12h et se termine à 1h au lieu de 6h ... ce n'est pas très utile. Oui, ça fait 6 fois plus vite mais personne ne sent la différence.

Et votre patron a un bon point. Microsoft a tendance à abandonner certaines de ses technologies. VB6, Linq-to-SQL, ASP classique, COM + ... Ceci est un risque pour tout logiciel non-open source (et logiciel open-source qui serait trop gros pour être maintenu par votre organisation en cas de manque de mise à jour). Si c'est au cœur de votre application, vous devriez en avoir un contrôle strict.

Les logiciels apportent une valeur ajoutée aux clients. Les améliorations techniques qui ne génèrent pas beaucoup d'avantages tout en introduisant des risques ne remplissent pas vraiment ce rôle.

Développez un POC (Proof of Concept) et faites-en une démonstration à votre supérieur. Le CEP devrait vous aider à déterminer les avantages réels de la technologie que vous proposez. Ensuite, vous et votre supérieur pouvez parler de la technologie et développer le pour et le contre pour la mettre en œuvre.

Vous devrez probablement passer plus de temps en dehors des heures de travail normales pour développer le POC.

En tant que note latérale du point de vue de SSIS, je l’ai utilisé et ai développé des packages SSIS. Nous avons en fait remplacé un processus de charge exclusif à l'aide de packages SSIS. Nous ne l'avons fait que parce que les clients se sont plaints des temps de chargement. Les temps de chargement ont considérablement diminué avec SSIS et tout le monde est devenu plus heureux.

SSIS est fondamentalement un flux de travail glisser-déposer avec très peu de programmation. Il faut un certain temps pour apprendre le fonctionnement de la boîte noire. Vous devrez donc en tenir compte si votre équipe commence à l’utiliser.

Bonnes réponses. Si ce n'est pas cassé, ne le répare pas. J'ajouterais seulement

• Bien que les problèmes de performances puissent être vrais, le mot "pourrait" est un drapeau rouge. Je faisais d’abord un diagnostic de performance afin d’obtenir une preuve du problème de performance avant d’engager des ressources pour le résoudre.

• Lors de l'examen de la dernière "solution" de Microsoft, il convient de noter que de nombreuses personnes ont été brûlées par ce que les États-Unis avaient autrefois vanté, mais par la suite déconseillé et par la suite déprécié. Si vous souhaitez que les logiciels fonctionnent pendant 10 ou 20 ans sans recodage important, soyez très prudent. Notre entreprise a été gravement blessée de cette façon.

Le chiffre d'affaires va être une considération pour votre patron. SSIS entre dans le domaine des administrateurs de bases de données par rapport à un programmeur possédant ces compétences. Si votre application n'utilise pas SSIS au-delà de la conversion initiale, je ne suis pas sûr qu'il soit logique de l'apprendre et de mettre au point de nouveaux programmeurs C #, car, à l'instar de votre équipe, la plupart d'entre eux n'en ont aucune expérience.

Vous pouvez faire remarquer à votre patron que SSIS est en fait une couche technologique plus ancienne que le .NET Framework, si vous revenez à ses racines en tant que "Data Transformation Framework" de SQL 7.0.

Votre patron a peut-être raison de penser que SSIS n'est qu'une partie des versions Standard et Enterprise de Microsoft Sql Server; c’est une grosse quantité de changement pour vos clients, alors que votre application, dans un scénario de petite entreprise, pourrait très bien fonctionner avec Sql Express (ou MySQL, qui fonctionne avec ADO.NET mais ne peut pas utiliser l'intégration SSIS).

Maintenant, laissez-moi être parfaitement clair. OMI, NIH n'est presque jamais une bonne chose pour une maison de développement de logiciels. Cela vous exclut de nombreux outils et services très puissants. C'est aussi hypocrite sur son visage; Votre entreprise a-t-elle écrit Visual Studio? Qu'en est-il du .NET Framework? Serveur SQL? Les fenêtres? Non. Vous construisez votre logiciel à partir des outils et des plates-formes que vous avez déjà (ainsi que vos clients). Par conséquent, si vous voyez un outil qui gagne en popularité et qui pourrait être utile dans l’exercice de votre activité principale, vous l’adopterez et vous apprendrez à vivre avec le risque de devoir maintenir votre mise en œuvre pour suivre les dernières évolutions. versions de ces outils, ou même les remplacer. Je parie que votre patron a d’abord développé le logiciel pour fonctionner sous Windows 95/98 ou à peu près (si ce n’est pas longavant cela, comme 3.0 / 3.1). Si tel est le cas, il a vu une demi-douzaine de versions de systèmes d'exploitation de stations de travail Windows aller et venir, et a dû mettre à jour son logiciel pour fonctionner sur les nouvelles plates-formes, et il est confronté à une autre avec XP officiellement EOLed. Bien qu'il puisse se plaindre, cela ne représente que le coût des affaires.

Cependant, l'attitude des NIH ne découle pas nécessairement du refus d'accepter une technologie, voire un certain nombre de technologies, qui peuvent être considérées comme utiles. Ces refus pourraient être fondés sur des analyses coûts-avantages parfaitement valables. Je travaille pour une entreprise de vidéosurveillance et de surveillance des alarmes et nous prenons la décision de prendre en charge, ou non, diverses nouvelles technologies ou de nouveaux produits au quotidien. Habituellement, la décision d’accepter une nouvelle technologie et la difficulté de l’éviter en même temps que notre logiciel existant de visionneuse et de gestion des alarmes pris en charge reposent principalement sur ce qu’elle vaut pour nos clients. J'ai récemment terminé un grand projet d'intégration avec un nouveau type d'enregistreur numérique, tout simplement parce qu'un de nos plus gros clients existants a annoncé qu'il effectuait la mise à niveau vers cet enregistreur numérique numérique à partir d'un autre produit de grande envergure, mais en retard sur le plan technologique. et ils le feraient avec ou sans notre aide. D'autre part, nous refusons régulièrement les nouveaux fabricants, même les grands noms de la maison, tout simplement parce que nos clients ne l'utilisent pas et que nous ne voyons pas l'intérêt de commencer à l'offrir, même si nous perdons quelques clients potentiels qui l'ont et ne le font pas. Je ne veux pas payer pour notre version de la même chose.

Je n'ai pas le temps d'écrire la conversion à l'ancienne, de m'enseigner moi-même SSIS et de l'écrire aussi avec la nouvelle façon de démontrer / tester les avantages (aucun d'entre nous n'a utilisé SSIS, il y aurait donc une période où apprendre à l'utiliser).

C'est un peu le problème, n'est-ce pas? Vous demandez à d'autres personnes de risquer leur productivité avec votre idée, et vous n'êtes pas disposé à faire l'impossible pour leur montrer que cela en vaut la peine. Le leadership technique nécessite de risquer votre réputation ou votre temps libre pour montrer que vos idées valent la peine d’avoir.

Essayez de voir les choses du point de vue de votre patron. On dirait que la fonctionnalité que vous essayez de remplacer est essentielle à ce que votre logiciel fait (voir son commentaire "foutu"). Un bon manager sait que vous externalisez votre activité principale à vos risques et périls. Il craint à juste titre de parier la ferme sur une technologie qui pourrait disparaître à l'avenir. Lorsque les fonctions essentielles sont impliquées, Not Invented Here est en fait une bonne chose.

Si la vitesse est une fonctionnalité, vous allez devoir trouver un autre moyen d'accélérer les choses. Autrement, si la rapidité compte plus pour vous que pour vos clients, je vous prie de laisser tomber et d’oublier.

Bien que le mérite de «ne pas réparer ce qui n'est pas brisé», je ne suis pas d'accord avec la réponse acceptée.

La réponse acceptée vient de la perspective que le problème n’est pas rompu. Du point de vue de la direction de niveau intermédiaire, cela est vrai. Si une analyse des coûts devait être effectuée sur le temps passé par les développeurs à créer et à gérer une solution ETL en C # par rapport à l'achat d'une solution prête à l'emploi, cela montrerait que la solution C # prend 3 à 4 fois plus de temps à créer. et maintenir et coûter jusqu'à 10 fois plus (j'ai cherché la référence sur les chiffres, mais je ne pouvais pas le trouver).

À moins que ce ne soit la compétence principale de l'entreprise, il y a très peu de raisons d'écrire et de gérer des transformations de données en C #. La solution locale sera lente, il y aura des erreurs (par exemple, des données corrompues), il y aura des cas extrêmes, il y aura peu de réutilisation entre les classes ETL, et ce sera fragile. Honnêtement, quel développeur veut passer ses journées à écrire et à maintenir ETL en C #? Je l'ai fait. C'est une charge de merde. C'est à peu près aussi loin que possible du travail créatif.

Utilisez un outil comme Informatica, une entreprise dont le métier est ETL. Ils travaillent sur ce problème depuis plus de 15 ans. Ils l'ont résolu. Leurs outils sont glisser-déposer, la réutilisabilité est intégrée, de même que les performances. La plupart des utilisateurs (les développeurs n'en ont pas aussi) peuvent créer des ETL avec les outils Informatica. Je n'essaie pas de vendre Informatica, utilisez n'importe quel outil. Il suffit de ne pas réinventer la roue.

À long terme, l’achat d’un outil tel que Informatica ou l’utilisation de SSIS permettra à la société d’économiser potentiellement des millions de dollars à long terme. Et le meilleur de tous vous n'aurez pas à maintenir l'ETL ou à en être responsable quand il casse.

J'ai déjà essayé de faire des tâches simples avec SSIS.

Cela peut être très énervant, car même les tâches les plus simples donnent naissance à des diagrammes de complexité de bas à moyen niveau (non, il n’ya pas d’autre moyen de le "coder" sauf les diagrammes). Et les problèmes de contrôle de source soulignés par la réponse de Jim, je n'étais pas au courant.

Problème secondaire: pour accélérer, je vous suggère de réduire la taille des transactions pour vos images en bloc. Dis, tous les 800 au lieu de 5000 rocords. Cela peut réduire la taille des E / S nécessaires pour prendre en charge cette transaction.