Mój dział specjalizuje się w konwertowaniu danych klientów do schematu naszej bazy danych, aby mogli korzystać z naszego oprogramowania.

W tej chwili mamy aplikacje C #, które zajmują IDataReader(99% czasu to a SqlDataReader), wykonują pewne czyszczenie i mapowanie, wstawiają go do DataRowobiektu, a następnie używają a SqlBulkCopydo wstawienia go do naszej bazy danych.

Czasami (szczególnie, gdy źródłowa baza danych zawiera obrazy jako varbinaryobiekty), proces ten może naprawdę ugrzęznąć dzięki transferowi SQL z serwera do aplikacji, aby po prostu odwrócić się i wrócić do serwera.

Wydaje mi się, że gdybyśmy ponownie napisali niektóre konwersje jako pakiety SSIS , mogłoby to znacznie przyspieszyć. Jednak największym kamiennym murem, na który wciąż wpadam, jest to, że mój szef, w stylu „ Nie wynalazłem tutaj” , odpycha się i mówi: „Co, jeśli Microsoft zrezygnuje z obsługi SSIS?

To nie pierwszy raz, kiedy trafiłem w „Co jeśli usuną tę funkcję ...?” odpowiedź od mojego szefa. Nie mam czasu, aby napisać konwersję po staremu, samemu nauczyć się SSIS, a także napisać nowy sposób wykazania / przetestowania korzyści (żadne z nas nie korzystało z SSIS, więc byłby okres, w którym moglibyśmy nauczyć się go używać).

Co powinienem zrobić w tej sytuacji? Przestać pchać nową technologię? Poczekaj, aż odejdzie z wydziału (jestem drugą osobą w podeszłym wieku w wydziale po nim, ale może minąć wiele lat, zanim odejdzie / przejdzie na emeryturę)? Znajdź nowy sposób, aby przestał się bać narzędzi innych firm?

Podejdę do tego z menedżerskiego punktu widzenia, ale pamiętaj, że jestem świadomy, że nie znam wszystkich szczegółów. Podsumuję to, co widzę:

1. Deweloper średniego poziomu, nazywamy go „Scott”, zaleca przepisanie starszego kodu do SSIS, aby poprawić wydajność ważnego procesu ProcessA.
2. ProcessA działa obecnie w stanie sprawnym bez znanych poważnych problemów.
3. ProcessA jest napisany przy użyciu zastrzeżonych narzędzi, w celu utrzymania wspólnej lub potencjalnie plemiennej wiedzy.
4. Zalecenia dotyczące przepisywania będą wymagać nowych narzędzi do obsługi.
5. Obecny personel nie ma udokumentowanego doświadczenia / wiedzy w zakresie nowych narzędzi.
6. Nowe narzędzia to stosunkowo niedawne zamienniki starszych narzędzi, a obsługa tych narzędzi może ulec rozsądnej zmianie w ciągu 4 kwartałów biznesowych.

Z tej perspektywy wszystko, co widzę, to duży wydatek pieniędzy ze strony firmy na ulepszenie procesu, który nie jest zepsuty . Z technicznego punktu widzenia widzę apelację, ale kiedy przejdziesz do sedna, wprowadzenie tej zmiany nie ma sensu z biznesowego punktu widzenia. Jeśli masz pod ręką personel z udokumentowanym doświadczeniem z SSIS i testami porównawczymi, aby wykazać ogromną poprawę tego procesu (pamiętaj, że ogromna poprawa MUSI być równa $$$), wynik może być nieco inny. Na obecną chwilę musiałbym jednak zgodzić się z zarządem (gdzieś właśnie umarło drzewo).

Jeśli chcesz wesprzeć przyjęcie SSIS i potencjalnie doprowadzić do tego refaktora, musisz zdobyć to doświadczenie i szkolenie przy mniejszych, mniej ważnych projektach. Zapewnij testy porównawcze i wsparcie dla SSIS i upewnij się, że cała infrastruktura i wsparcie są na miejscu, zanim zarząd nawet rozważy wprowadzenie zmiany. Gdy narzędzie będzie używane gdzie indziej, ludzie w zespole doświadczą jego używania, a czynnik „komfortu” w biznesie, który zapewni wsparcie, nie zmieni i nie usunie wszystkiego, istnieje większe prawdopodobieństwo, że przekonasz kogoś do swojego punktu widzenia. Bez nich za pomocą tego argumentu szczekasz na niewłaściwe drzewo.

Choć jest to głupie, czasem „najlepszy” sposób nie jest najlepszym sposobem.

Edycja: W odpowiedzi na niektóre aktualizacje pytania opublikuję niewielką modyfikację mojej odpowiedzi.

Jeśli proces napotyka jakieś trudności, jego przepisanie nadal będzie kosztownym przedsięwzięciem. Możesz zastanowić się, jaki byłby koszt dostrojenia istniejącego kodu w stosunku do przepisywania pakietu. Weź pod uwagę wpływ nie tylko na oprogramowanie, ale także na wszelkie procesy łączenia się ludzi. Przy próbie uzyskania wpisowego dla menedżera do przepisania, nadal zawsze sprowadza się to do pieniędzy. O ile nie możesz wykazać, że obecny trud kosztuje teraz pieniądze lub stanie się duży łącznie, zarząd nadal nie zobaczy korzyści. Koszt ten niekoniecznie musi mieć charakter finansowy. Jeśli spowolnienie zagraża systemowi powodującemu przestój, wprowadza wektory wtargnięcia lub inny „trudny do oszacowania” objaw, być może trzeba znaleźć sposób na przełożenie tego problemu na ekwiwalent ryzyka pieniężnego. Na przykład wektor wtargnięcia, może prowadzić do włamania, które może prowadzić do utraty, kradzieży lub uszkodzenia danych. Firma może stracić reputację lub może zakończyć się koniecznym audytem bezpieczeństwa. Kluczem jest skłonienie tego menedżera do uznania wymiernych korzyści wynikających ze zmiany.

Breaking Things To umiejętność

Pracowałem w zdecydowanie zbyt wielu miejscach, które przyjęły argument „jeśli nie jest zepsuty” do tego stopnia, że ​​nie wprowadziły innowacji, a kiedy są w końcu zmuszone do innowacji, reagują nadmiernie, zmieniając wszystko . Po prostu dlatego, że brakuje im doświadczenia w łamaniu rzeczy .

Do zniszczenia potrzeba dojrzałości, umiejętności i doświadczenia.

Zespoły programistów, które zawsze grają bezpiecznie, są najłatwiejsze do pokonania przez konkurenta. Tylko zespoły, które zawiodły, popełniły błędy i popsuły rzeczy, są w stanie naprawdę rzetelnie oceniać ryzyko.

Utrzymanie status quo

Chociaż to prawda, obecny system spełnia aktualne wymagania biznesowe. Nie dotyczy to przyszłych nieprzewidzianych zmian tych wymagań. Jak mówi stare przysłowie „fortuna woli przygotowane”.

To pytanie nie ma nic wspólnego z SQL ani wydajnością. Chodzi o zadanie pytania „czy jest lepszy sposób?” i nie bojąc się spróbować alternatywy.

Twój szef cierpi na przypadek utrzymania status quo .

Majowie

Nic tak naprawdę nie działa idealnie.

Majowie dalej uprawiali żywność na zboczu gór. Dopóki wszystkie składniki odżywcze nie zostały zmyte i nie mieli sposobu na wyżywienie swoich ludzi. Robili to samo, dopóki nie było za późno.

Zakładanie, że będziesz mieć czas na naprawienie problemu, gdy problem się pojawi, jest błędem.

Co robić?

Twój szef cierpi na przypadek uwarunkowania. Ludzie, którzy akceptują status quo, często to robią, ponieważ nie mają możliwości podejmowania trudnych decyzji. W obliczu wyzwania będą zazwyczaj wybierać opcję najbliższą temu, co znają.

Strach dla niego jest wielką motywacją. Lęk przed nieznanymi lub zmieniającymi się warunkami wstrząsa jego perspektywą na status quo. Będzie dążył do jak najszybszego przywrócenia normalnych warunków.

Musisz przedstawiać pomysły w sposób nie powodujący konfliktu. Spróbuj znaleźć wspólną płaszczyznę między tym, co chciałbyś zrobić z tym, co już jest status quo. Przedstaw argumenty, które zmniejszają jego lęk przed zmianą, i zapewniaj, że chcesz wykonać zadanie, które nie spowoduje znaczących zmian.

Rób kroki dziecka

Najlepiej byłoby oferować zmiany, które przesuwają projekt w pożądanym kierunku, ale za pośrednictwem małych projektów przyrostowych. Zamiast tego uderz swojego szefa wielkim pytaniem o wsparcie SSIS. Zaoferuj utworzenie w kodzie warstwy rozdzielającej, która pozwoliłaby na podłączenie „alternatywnych” metod przetwarzania tabel z dużymi załącznikami. Następnie możesz przejść do zalecania SSIS, ponieważ wszystkie wymagania wstępne zostały już dodane do projektu. Zmniejsza to ryzyko, jakie przewiduje twój szef, akceptując zmianę.

To wymaga czasu

Z mojego doświadczenia wynika, że ​​osoby podejmujące ryzyko utrzymują projekt w ruchu, a posiadacze status quo są jak mur z cegły. Trwałość jest twoją jedyną opcją na przełamanie barier. Oczekuj, że nadal będziesz słyszeć „ Nie” w odpowiedzi na twoje pytania.

Kiedy przychodzi czas na innowacje. Twój szef szybko się do ciebie zwróci, ponieważ okazujesz nieustraszoność w obliczu zmiany. Będzie czegoś, czego będzie szukać osoba status quo, a za swoje wysiłki zostaniesz nagrodzony. Nawet jeśli żadne z twoich wcześniejszych zapytań nie zostało zaakceptowane. Szybko staniesz się niezastąpionym aktywem w firmie stojącej przed zmianą, która obejmuje niezmienność.

Wydaje mi się, że gdybyśmy ponownie napisali niektóre konwersje jako pakiety SSIS, mogłoby to znacznie przyspieszyć. Jednak największym kamiennym murem, na który wciąż wpadam, jest to, że mój szef, w stylu „Nie wynalazłem tutaj”, odpycha się i mówi: „Co, jeśli Microsoft zrezygnuje z obsługi SSIS? Będziemy mieć cały ten przestarzały kod i zostaniemy spieprzeni”.

Moim zdaniem sceptycyzm wobec SSIS jest uzasadniony.

• Doświadczeni programiści nienawidzą czarnych skrzynek, a wewnątrz pakietu SSIS dzieje się wiele magii.
• Bardzo brakuje wsparcia kontroli źródła dla pakietów SSIS. Różnicowanie i scalanie plików dtsx SSIS może być koszmarem, jeśli pakiety dtsx nie są wystarczająco modułowe.
  • Natomiast aplikacje konsolowe C # są bardzo przejrzyste. Zawsze możesz postępować zgodnie z kodem, aby dowiedzieć się, co się dzieje.

Weź również pod uwagę, że twój szef jest na haku, jeśli coś pójdzie nie tak.

• Dlatego ma on prawo do nadrzędnej / jedynej opinii w tej sprawie.

Nie mam czasu, aby napisać konwersję po staremu, samemu nauczyć się SSIS, a także napisać nowy sposób wykazania / przetestowania korzyści (żadne z nas nie korzystało z SSIS, więc byłby okres, w którym moglibyśmy nauczyć się go używać).

Co powinienem zrobić w tej sytuacji? Przestać pchać nową technologię? Poczekaj, aż odejdzie z wydziału (jestem drugą osobą w podeszłym wieku w wydziale po nim, ale może minąć wiele lat, zanim odejdzie / przejdzie na emeryturę)? Znajdź nowy sposób, aby przestał się bać narzędzi innych firm?

Zalecam, abyś nauczył się SSIS wystarczająco dobrze, abyś mógł wykazać jego zalety.

A jeśli po samokształceniu okaże się, że SSIS oferuje znaczącą przewagę nad bardziej „tradycyjnym” podejściem i nadal nie możesz przekonać swojego szefa do zmiany kursu, to polecam znaleźć inną pracę, w której możesz użyj SSIS.

Odpowiedź, z której prawie zawsze korzystasz, pochodzi od większości menedżerów:

„To nie jest tego warte, działa teraz i będzie wymagać czasu na zmianę”.

I ogólnie rzecz biorąc, jest to ważne. Nie zawsze jest to jednak uzasadniony argument, ponieważ głównym problemem związanym z syndromem „nie wymyślono tutaj” nie jest to, czy rzeczy działają, czy nie działają, ale technologia ta jest bezcelowo przepisywana , marnuje godziny pracy firmy i szkodzi znacznej wartości od dostarczanego produktu.

Przed podjęciem decyzji o tym, co należy zrobić, musisz ustalić, czy naprawdę nie wymyślono tutaj. Technologia wewnętrzna mogła zostać napisana z jakiegoś powodu .

Znaki, że technika została przepisana z jakiegoś powodu:

• Technologia, którą sprzedajesz, jest również produktem . Jeśli jesteś dostawcą bazy danych, korzystającym z kodu MySQL, bez względu na to, ile czasu to zaoszczędzi, jest to niebezpieczny pomysł z wielu powodów.
• Wewnętrzna technologia jest dobrze utrzymana i skutecznie eliminuje niedociągnięcia gotowego rozwiązania, zapewniając jednocześnie porównywalną funkcjonalność podstawową.
• Technologia poprawia produktywność całego zespołu programistów, a nowi programiści są łatwo sprzedawani na podstawie tego, dlaczego są używane.
• Istnieją inne przykłady, w których firma z powodzeniem przyjęła inne technologie zewnętrzne .
• Gdyby rozwiązanie OTS zostało przerwane lub zepsute, miałoby to natychmiastowy i poważny wpływ na Twoją firmę .
• Firma jest tak duża , że ma zasoby do pisania wysokiej jakości narzędzi przy niskim koszcie (na przykład Google może być w stanie napisać bazę danych, która kosztuje mniej niż 1000 USD / licencję MS SQL)

Innymi słowy, zespół rozumie wady związane z ponownym rozwiązywaniem już rozwiązanych problemów, ale rozsądnie robił wyjątki tam, gdzie miało to sens z biznesowego punktu widzenia.

Znaki „Nie wymyślono tutaj”:

• Wygląda na to, że wszystko jest wewnętrzne , a na wszystko są wymówki: „uh, to było zbyt wolne”, „uh, to Microsoft, nienawidzimy Microsoftu”, „uh, wygląda na naprawdę trudne w użyciu” itp.
• W przypadkach, w których stosuje się technologię zewnętrzną, słyszysz „tak, to śmierdzi, a my w końcu planujemy napisać własne ”.
• Właściciele tych komponentów nie mają innych zadań, nad którymi mogliby pracować.
• Widzisz większość nowych programistów z powszechnie akceptowanym zestawem umiejętności, ale zajmuje im to dużo czasu, zanim wdrożą narzędzia wewnętrzne
• Po dokładnej analizie okazuje się, że przejście z rozwiązania OTS do niestandardowego lub innego rozwiązania OTS w „co, jeśli zostanie ono przerwane!” scenariusz miałby minimalny wpływ na działalność . Na przykład, gdyby String.Join()zostały usunięte z .NET Framework, ponowna implementacja do niestandardowej StringJoin()metody byłaby trywialna.

Innymi słowy, NIH jest wzorem niezachowania obiektywności i realistyczności w przypadkach, w których zamiast własnego kodu używana jest technologia zewnętrzna.

Kiedy technika jest przepisywana z jakiegoś powodu, zgłaszanie wątpliwości powinno być chwalone i doceniane przez przełożonych. Kiedy technologia została wdrożona, powinna była być ostrożna, a od czasu do czasu sprawdzenie decyzji jest dobre dla firmy. Rzeczy zmieniają się z czasem i możesz mieć ważny punkt. Jeśli możesz podać liczby dotyczące czasu zmarnowanego w przeszłości, przewidywanych kosztów zamiany i innych informacji, możesz (teoretycznie) uzasadnić zamianę.

Zrozum, że biorąc pod uwagę twoje doświadczenie, mogą nie zgadzać się z twoimi liczbami, ale niezależnie od tego, powinni cię przynajmniej wysłuchać. Zdobycie szacunku może trochę potrwać.

Jeśli rozmowy nie można nawet przywołać, nawet jeśli jesteś uprzejmy, może to być po prostu „Nie wymyślono tutaj”. W takim przypadku najprawdopodobniej jest to kwestia osobowościowa lub polityczna, której prawdopodobnie nie da się łatwo rozwiązać. Praca w środowisku mocno obciążonym ciągłymi zmianami jest toksyczna dla programistów i firmy. Biegać.

(Uwaga dodatkowa: w większości firm NIH zawsze zawiera element, ale jest on na akceptowalnym poziomie i pod warunkiem, że regularnie sprawdzają kod i praktyki. W dłuższej perspektywie wszyscy jesteśmy do pewnego stopnia winni, ale to nigdy nie staje się problemem).

Cóż, chodzi o analizę kosztów i korzyści.

Co zyskujesz przepisując go do SSIS? Prędkość? Czy to ma znaczenie? Jeśli jest to proces wykonywany w interfejsie GUI i marnujący czas, to prawdopodobnie dobrym pomysłem jest przyspieszenie go, ponieważ pieniądze wydane na jego zmianę zostaną odzyskane przez bardziej zadowolonego klienta lub wewnętrznego pracownika wykonującego swoją pracę zamiast czekam na oprogramowanie. Ale jeśli jest to partia nocna, która zaczyna się o 12 rano i kończy się o 1 zamiast 6 rano ... nie ma sensu. Tak, to 6 razy szybciej, ale nikt nie poczuje różnicy.

A twój szef ma rację. Microsoft często rezygnuje z niektórych technologii. VB6, Linq-to-SQL, ASP classic, COM + ... Jest to ryzyko związane z każdym oprogramowaniem innym niż oprogramowanie open source (i oprogramowaniem typu open source, które byłoby zbyt duże, aby utrzymać Twoją organizację w przypadku braku aktualizacji). Jeśli ma to kluczowe znaczenie dla twojej aplikacji, powinieneś mieć nad nią ścisłą kontrolę.

Oprogramowanie polega na zwiększaniu wartości dodanej dla klienta, a ulepszenia techniczne, które nie przynoszą dużych korzyści, a jednocześnie wprowadzają ryzyko, nie spełniają tej roli.

Opracuj POC (Proof of Concept), a następnie zaprezentuj go przełożonemu. POC powinien pomóc ci określić rzeczywiste korzyści z proponowanej technologii. Wtedy ty i twój przełożony możecie porozmawiać o technologii i opracować zalety i wady, aby ją wdrożyć.

Prawdopodobnie będziesz musiał poświęcić trochę więcej czasu poza normalnym czasem pracy, aby opracować POC.

Na marginesie, z punktu widzenia SSIS, wykorzystałem go i opracowałem pakiety SSIS. W rzeczywistości zastąpiliśmy zastrzeżony proces ładowania przy użyciu pakietów SSIS. Zrobiliśmy to tylko dlatego, że faktyczni klienci skarżyli się na czasy ładowania. Czasy ładowania znacznie spadły dzięki SSIS i wszyscy byli szczęśliwsi.

SSIS jest w zasadzie procesem przeciągania i upuszczania przy bardzo niewielkim zaangażowaniu w programowanie. Nauczenie się, jak działa czarna skrzynka, zajmuje trochę czasu, więc musisz wziąć to pod uwagę, jeśli Twój zespół zacznie z niej korzystać.

Dobre odpowiedzi Jeśli nie jest zepsuty, nie naprawiaj go. Chciałbym tylko dodać

• Podczas gdy obawy dotyczące wydajności mogą być prawdziwe, słowo „może” jest czerwoną flagą. Najpierw przeprowadzę diagnostykę wydajności, więc będę miał dowód na to, na czym polega problem z wydajnością, zanim przekażę środki na jego rozwiązanie.

• Rozważając najnowsze „rozwiązanie” firmy Microsoft, należy wziąć pod uwagę, że wiele osób zostało spalonych przez to, co stwardnienie rozsiane reklamowało, ale później przestało być obsługiwane, a następnie zostało wycofane. Jeśli chcesz, aby oprogramowanie działało przez 10 lub 20 lat bez poważnego przekodowywania, powinieneś być bardzo ostrożny. Nasza firma została poważnie zraniona w ten sposób.

Twój obrót będzie brany pod uwagę. SSIS wkracza na arenę DBA w porównaniu do programisty posiadającego ten zestaw umiejętności. Jeśli twoja aplikacja nie korzysta z SSIS poza początkową konwersją, nie jestem pewien, czy warto się go uczyć i przyspieszać nowych programistów C #, ponieważ podobnie jak zespół, większość nie ma z tym żadnego doświadczenia.

Możesz wskazać swojemu szefowi, że SSIS jest w rzeczywistości starszą warstwą technologiczną niż .NET Framework, jeśli wrócisz do jego korzeni jako „Data Transformation Framework” SQL 7.0.

Twój szef może mieć rację w tym, że SSIS jest tylko częścią Standardowej i Enterprise wersji Microsoft Sql Server; jest to dość duża zmiana dla twoich klientów, aby kucać, gdy twoja aplikacja, w scenariuszu dla małych firm, może dobrze działać z Sql Express (lub MySQL, jeśli chodzi o to, który działa z ADO.NET, ale nie może użyj integracji SSIS).

Teraz pozwól mi być całkowicie jasny; IMO, NIH prawie nigdy nie jest dobrą rzeczą dla domu programistycznego. To blokuje dostęp do wielu bardzo potężnych narzędzi i usług. Jest również obłudny na twarzy; czy twoja firma napisała Visual Studio? Co powiesz na .NET Framework? Serwer SQL? Windows? Nie. Tworzysz oprogramowanie na podstawie narzędzi i platform, które już masz (podobnie jak twoi klienci). Dlatego jeśli zobaczysz narzędzie, które zyskuje ogólną akceptację i może być przydatne w prowadzeniu podstawowej działalności, zastosuj je i naucz się żyć z ryzykiem, że będziesz musiał utrzymać wdrożenie, aby dotrzymać kroku najnowszemu wersje tych narzędzi, a nawet je zastąpić. Założę się, że twój szef najpierw opracował oprogramowanie do pracy w systemie Windows 95/98 lub innym (jeśli nie długowcześniej, jak 3.0 / 3.1). Jeśli tak, widział, że pojawia się i odchodzi z pół tuzina wersji systemów operacyjnych Windows, i musiał zaktualizować swoje oprogramowanie, aby działało na nowszych platformach, i ma do czynienia z kolejną z XP oficjalnie EOLed. Chociaż może narzekać, to po prostu koszt prowadzenia działalności.

Jednak podejście NIH niekoniecznie wynika z odmowy przyjęcia jednej, a nawet kilku technologii, które mogą być postrzegane jako pomocne. Te odmowy mogłyby opierać się na doskonale uzasadnionych analizach kosztów i korzyści. Pracuję w firmie monitorującej i monitorującej alarmy i codziennie podejmujemy decyzje o wsparciu różnych technologii lub produktów. Zwykle decyzja o przyjęciu nowej technologii i ból wtrącania się jej wraz z naszą istniejącą stertą obsługiwanego oprogramowania do przeglądania i zarządzania alarmami, zależy przede wszystkim od tego, co jest warte dla naszych klientów. Niedawno zakończyłem duży projekt integracyjny z nowym rodzajem rejestratora DVR, po prostu dlatego, że jeden z naszych największych istniejących klientów powiedział, że aktualizuje go do innego rejestratora DVR z innego znanego, ale opóźnionego technologicznie produktu DVR, i zrobiliby to z naszą pomocą lub bez niej. Z drugiej strony regularnie odrzucamy nowych producentów, nawet głównych nazwisk domowych, po prostu dlatego, że nasi klienci nie używają go i nie widzimy żadnej wartości w rozpoczynaniu jego oferowania, nawet jeśli straci nas kilku potencjalnych klientów, którzy go mają i nie „ chcę zapłacić za naszą wersję tego samego.

Nie mam czasu, aby napisać konwersję po staremu, samemu nauczyć się SSIS, a także napisać nowy sposób wykazania / przetestowania korzyści (żadne z nas nie korzystało z SSIS, więc byłby okres, w którym moglibyśmy nauczyć się go używać).

To taki problem, prawda? Prosisz innych ludzi, aby zaryzykowali swoją produktywność w związku z twoim pomysłem, i nie jesteś skłonny iść na całość, aby pokazać im, że warto. Techniczne przywództwo wymaga albo ryzykowania twojej reputacji, albo wolnego czasu, aby pokazać, że twoje pomysły są warte posiadania.

Staraj się widzieć rzeczy z perspektywy szefa. Wygląda na to, że funkcja, którą próbujesz zastąpić, ma kluczowe znaczenie dla tego, co robi twoje oprogramowanie (por. Jego „wkręcony” komentarz). Dobry menedżer wie, że zlecasz swoją podstawową działalność na własne ryzyko. Słusznie martwi się postawieniem farmy na jakąś technologię, która może zniknąć w przyszłości. Gdy zaangażowane są podstawowe funkcje, nie wymyślone tutaj jest właściwie dobrą rzeczą.

Jeśli prędkość jest cechą, będziesz musiał znaleźć inny sposób na przyspieszenie. W przeciwnym razie, jeśli prędkość ma większe znaczenie dla ciebie niż dla twoich klientów, mówię, porzuć ją i zapomnij o tym.

Chociaż warto „nie naprawiać tego, co nie jest zepsute”, nie zgadzam się z przyjętą odpowiedzią.

Przyjęta odpowiedź pochodzi z perspektywy, że problem nie zostanie rozwiązany. Z punktu widzenia zarządzania średniego szczebla jest to prawdą. Jeśli analiza kosztów miałaby zostać przeprowadzona w czasie, który deweloperzy poświęcili na stworzenie i utrzymanie rozwiązania ETL w języku C # w porównaniu do zakupu rozwiązania „po wyjęciu z pudełka”, to pokazałoby, że utworzenie rozwiązania w języku C # zajmuje od 3 do 4 razy dłużej i utrzymywać i kosztować nawet 10 razy więcej (szukałem referencji na liczbach, ale nie mogłem jej znaleźć).

O ile nie jest to podstawowa kompetencja firmy, nie ma powodu, aby pisać i utrzymywać transformacje danych w języku C #. Własne rozwiązanie będzie powolne, pojawią się błędy (tj. Uszkodzone dane), pojawią się przypadki krawędziowe, ponowne użycie między klasami ETL będzie niewielkie, i będzie kruche. Szczerze mówiąc, który programista chce spędzić swoje dni na pisaniu i utrzymywaniu ETL w C #? Zrobiłem to. To mnóstwo bzdur. Jest tak daleko od pracy twórczej, jak tylko się da.

Skorzystaj z narzędzia takiego jak Informatica, firma, której działalność to ETL. Pracowali nad tym problemem od ponad 15 lat. Mają to rozwiązane. Ich narzędzia są „przeciągnij i upuść”, możliwość ponownego użycia jest wbudowana, podobnie jak wydajność. Większość osób (tj. Programiści też nie mają takiej możliwości) może tworzyć ETL za pomocą narzędzi Informatica. Nie próbuję sprzedawać Informatica, używać żadnego narzędzia. Tylko nie wymyślaj od nowa koła.

W dłuższej perspektywie zakup narzędzia, takiego jak Informatica lub korzystanie z SSIS, pozwoli firmie zaoszczędzić potencjalnie miliony na dłuższą metę. A co najlepsze, nie będziesz musiał utrzymywać ETL ani ponosić odpowiedzialności za to, gdy się zepsuje.

Próbowałem już wcześniej SSIS do wykonywania prostych zadań.

Może to być bardzo denerwujące, ponieważ nawet proste zadania rodzą diagramy złożoności od niskiego do średniego poziomu (nie, nie ma innego sposobu na „zakodowanie” oprócz diagramów). I problemy z kontrolą źródła wskazane przez odpowiedź Jima nie wiedziałem.

Problem uboczny: Aby przyspieszyć, sugeruję zmniejszenie wielkości transakcji dla obrazów. Powiedz, co 800 zamiast 5000 rocordów. Może zmniejszyć rozmiar operacji we / wy potrzebnych do obsługi tej transakcji.