Bölümüm, yazılımımızı kullanabilmeleri için müşteri verilerini veritabanı şemasına dönüştürmekte uzmandır.

Şu anda, IDataReader(zamanın% 99'unu a SqlDataReader) alan, temizleme ve eşleme yapan, bir DataRownesneye yerleştiren ve ardından SqlBulkCopyveritabanına eklemek için a kullanan C # uygulamalarımız var .

Bazen (özellikle kaynak veritabanı görüntüler olarak varbinarynesneler içerdiğinde ), bu işlem sunucudan uygulamaya doğrudan bir SQL aktarımıyla başlayabilir ve daha sonra geriye dönüp sunucuya geri dönebilir.

Bazı dönüşümleri SSIS paketleri olarak yeniden yazarsak olayları çok hızlandırabilirim. Bununla birlikte, karşılaştığım en büyük taş duvar, patronum, Invented Here modasında, geri iterek ve "Peki ya Microsoft SSIS için destek bırakırsa? Tüm bu eski kodlara sahip olacağız ve kodlanacağız."

İlk defa "Bir o özelliği kaldırırlarsa ne olur?" Demiştim. patronumdan cevap. Dönüşümü eski yoldan yazma, kendime SSIS'i öğretme ve ayrıca yararları göstermek / test etmek için yeni bir yol yazmak için zamanım yok (Hiçbirimiz SSIS'i kullanmamıştık, böylece bir süre olacaktı. nasıl kullanılacağını öğrenmek zorundayım.

Bu durumda ne yapmalıyım? Yeni teknolojiyi zorlamayı bırak? Departmanı terk etmesini bekleyin (Ben, ondan sonra departmanın en çok ikinci kişisiyim, ancak istifa etmesi / emekli olması yıllar önce olabilir)? 3. parti araçlarından korkmasını durdurmak için yeni bir yol buldun mu?

Bunu bir yönetimsel bakış açısıyla çözeceğim, ancak tüm ayrıntılara sahip olmadığımı bildiğimi unutmayın. Gördüklerimi özetleyeceğim:

1. Orta seviye geliştirici, ona "Scott" diyeceğiz, önemli işlem ProcessA'nın performansını iyileştirmek için eski kodun SSIS'e yeniden yazılmasını önerir.
2. ProcessA şu anda bilinen önemli bir sorunu olmayan işleyen bir durumda davranıyor.
3. ProcessA, korumak için yaygın veya potansiyel olarak kabile bilgisini kullanan özel araçlarla yazılmıştır.
4. Yeniden yazma önerisi, desteklenmesi için yeni araçlar gerektirecektir.
5. Mevcut personelin yeni araçlarla belgelendirilmiş bir deneyimi / bilgisi yoktur.
6. Yeni araçlar, eski takımlara nispeten yakın zamanda yapılan değişikliklerdir ve bu araçlara yönelik destek 4 iş çeyreğinde makul ölçüde değişebilir.

Bu açıdan bakıldığında, gördüğüm tek şey şirketin kırılmayan bir süreci geliştirmek için büyük miktarda para harcaması . Teknik açıdan bakıldığında temyizi görebiliyorum, ancak tam anlamıyla aşağı indiğinizde, bu değişikliği yapmanın bir anlamı yok. Bu süreçte muazzam bir iyileşme göstermek için SSIS ile belgelendirilmiş tecrübesi ve referansları olan personeliniz varsa (akılda tutulması gereken, toplu iyileştirmenin $$$'e eşit olması GEREKİR), sonuç biraz farklı olabilir. Şimdi olduğu gibi, yönetimle aynı fikirdeyim (bir ağaç daha yeni öldü).

SSIS'nin benimsenmesini teşvik etmek ve potansiyel olarak bu refraktöre yol açmak istiyorsanız, bu deneyimi ve eğitimi daha küçük, daha az önemli projelerle kazanmanız gerekir. SSIS için kriterler ve destek sağlayın ve yönetimin değişikliği yapmayı düşünmeden önce tüm altyapı ve desteğin yerinde olduğundan emin olun. Başka bir yerde kullanımda olan araca sahip olduğunuzda, ekibin kullanıcıları kullanımı konusunda deneyimlidir ve desteği destekleyen her şeyi değiştirmeyecek ve ortadan kaldıramayacak bir iş "konfor" faktörü, birisini bakış açınıza sallama olasılığınız daha yüksek olacaktır. Bunlar olmadan, yanlış tartışmayı o tartışmaya soktun.

Göründüğü kadar aptal, bazen "en iyi" yol en iyi yol değildir.

Düzenleme: Soruyla ilgili bazı güncellemelere cevap olarak, cevabımda ufak bir değişiklik yapacağım.

Eğer süreç bir tür sıkıntı yaşıyorsa, yeniden yazmak yine de masraflı bir girişim olacaktır. Mevcut kodu ince ayar yapmanın maliyetinin paketi yeniden yazmaya karşı ne olacağını düşünebilirsiniz. Etkileri yalnızca yazılıma değil, insan arayüz işlemlerine de uygulayın. Yönetimin yeniden yazılmasını sağlamak için giriş yapmaya çalıştığında, yine de her zaman paraya düşecek. Mevcut sıkıntının şu an için pahalıya mal olduğunu ya da toplamda büyük olacağını göstermediğiniz sürece, yönetim faydayı görmeyecektir. Bu maliyet mutlaka doğada finansal olmayabilir. Yavaşlama, duruş süresine neden olan bir sistemi tehlikeye atarsa, izinsiz giriş vektörleri veya başka bir "ölçülmesi zor" semptom ortaya çıkarırsa, bu sorunu parasal risk eşdeğerine dönüştürmenin bir yolunu bulmanız gerekebilir. Bir izinsiz giriş vektörü, örneğin Kayıp, çalıntı veya bozuk veriye neden olabilecek izinsiz girişlere neden olabilir. Şirket itibarını kaybedebilir veya gerekli bir güvenlik denetiminde başarısız olabilir. Önemli olan, yöneticiyi söz konusu değişikliğin ölçülebilir faydalarını fark etmesini sağlamaktır.

Bir Şeyleri Kırmak Bir Beceridir

“Kırılmamışsa” argümanını benimseyen çok fazla yerde çalıştım, yenilik yapmakta başarısız oldukları noktaya dair bir argüman ve nihayet yenilik yapmak zorunda kaldıklarında her şeyi değiştirerek tepki gösteriyorlar . Çünkü onlar bir şeyleri kırma deneyiminden yoksunlar .

Bir şeyleri kırmak için olgunluk, beceri ve tecrübe gerekir.

Her zaman güvenli bir şekilde oynayan geliştirme ekipleri, bir yarışmacının aşması en kolay olanıdır. Sadece başarısız olmuş, hata yapmış ve kırılmış takımlar gerçekten dürüst risk değerlendirmeleri yapabilirler.

Statükoyu Tutma

Doğru olsa da, mevcut sistem mevcut işletme gereksinimlerini karşılar. Bu, gelecekteki bu gereksinimlerdeki öngörülemeyen değişiklikler için geçerli değildir. Eski atasözünün dediği gibi "servet hazırlananları tercih eder".

Bu sorunun SQL veya performansla ilgisi yok. "Daha iyi bir yol var mı?" Sorusunu sormakla ilgili. ve bir alternatif denemekten korkmamak.

Patronun, Statükoyu Tutma davasından muzdarip .

Maya'nın

Hiçbir şey gerçekten mükemmel çalışmıyor.

Mayalılar yiyeceklerini dağların yanında yetiştirmeye devam ediyorlardı. Bütün besinler yıkanana ve halklarını beslemek için hiçbir yolu yoktu. Çok geç olmadan aynı şeyi yapmaya devam ettiler.

Sorunun kendisini gösterdiğinde bir sorunu çözmek için zamanınız olacağını varsayalım.

Ne yapalım?

Patronun şartlanma sorunu yaşıyor. Statükoyu kabul eden insanlar sık ​​sık bunu yapar, çünkü zor kararlar verememektedirler. Bir zorlukla karşı karşıya kaldıklarında, aşina olduklarına en yakın seçeneği seçme eğilimindedirler.

Onun için korku, büyük bir motivasyon. Bilinmeyen veya değişen koşullardan korkma, statükonun ne olduğu konusundaki bakış açısını sallar. Koşulları olabildiğince çabuk normale döndürmeye çalışacak.

Fikirleri çelişkili olmayan bir şekilde sunmanız gerekir. Halihazırda statükonun ne olduğu ile yapmak istedikleriniz arasında ortak bir zemin bulmaya çalışın. Değişim korkusunu azaltan argümanlar sunun ve önemli bir değişime neden olmayacak bir görevi tamamlamak istediğinize dair güvence verin.

Bebek Adımlarını Atın

Projeyi istediğiniz yöne çeken, ancak küçük artımlı projeler yoluyla değişiklik önermek en iyisi olacaktır. Aksine, SSIS'yi desteklemekle ilgili büyük bir soru ile patronunuza vurun. Kodda, büyük ekleri olan tabloları işlemek için "alternatif" yöntemler eklemenize izin verecek bir ayırma katmanı oluşturma teklifi. Daha sonra, projeye önceden eklenmiş tüm önkoşulları içeren SSIS'i önermek üzere ilerleyebilirsiniz. Bu, patronunuzun değişikliği kabul ederek öngördüğü riski azaltır.

O zaman alır

Tecrübelerime göre risk alanların bir projeyi harekete geçirdiği ve statüko kalelerinin bir tuğla duvar gibi olduğu. Kalıcılık, engellerini aşmak için tek seçeneğinizdir. Sorularınız için Hayır'ı dinlemeye devam edin.

Yenilik zamanı geldiğinde. Patronun sana çabucak dönecek, çünkü değişim karşısında korkusuzluk gösterdin. Bir statükoyu arayan kişi arayacak ve çabalarınız için ödüllendirileceksiniz. Önceki sorularınızdan hiçbiri kabul edilmediyse bile. Değişimle karşı karşıya kalan değişimle karşı karşıya olan bir şirkette hızla yeri doldurulamaz bir varlık haline geleceksiniz.

Bazı dönüşümleri SSIS paketleri olarak yeniden yazarsak olayları çok hızlandırabilirim. Bununla birlikte, karşılaştığım en büyük taş duvar, patronum, Invented Here modasında, geri iterek ve "Peki ya Microsoft SSIS için destek bırakırsa? Tüm bu eski kodlara sahip olacağız ve mahkum olacağız."

Bence SSIS hakkında şüphecilik geçerli.

• Tecrübeli geliştiriciler kara kutulardan nefret eder ve SSIS paketinin içinde gerçekleşen çok fazla sihir vardır.
• SSIS paketleri için kaynak kontrol desteği kesinlikle yoksundur. Eğer dtsx paketleriniz yeterince modüler değilse, SSIS dtsx dosyalarının dağılması ve birleştirilmesi kabus olabilir.
  • Buna karşılık, C # konsol uygulamaları çok şeffaf. Neyin yanlış gittiğini anlamak için her zaman kodu takip edebilirsiniz.

Ayrıca, bir şeyler ters giderse, patronunuzun kancada olduğunu düşünün.

• Bu nedenle, konuyla ilgili tek / tek görüşe sahip olma hakkına sahiptir.

Dönüşümü eski yoldan yazma, kendime SSIS'i öğretme ve ayrıca yararları göstermek / test etmek için yeni bir yol yazmak için zamanım yok (Hiçbirimiz SSIS'i kullanmamıştık, böylece bir süre olacaktı. nasıl kullanılacağını öğrenmek zorundayım.

Bu durumda ne yapmalıyım? Yeni teknolojiyi zorlamayı bırak? Departmanı terk etmesini bekleyin (Ben, ondan sonra departmanın en çok ikinci kişisiyim, ancak istifa etmesi / emekli olması yıllar önce olabilir)? 3. parti araçlarından korkmasını durdurmak için yeni bir yol buldun mu?

Faydalarını gösterebilmeniz için SSIS'i yeterince iyi öğrenmenizi tavsiye ederim .

Kendi çalışmanızdan sonra, SSIS'in daha "geleneksel" yaklaşıma göre önemli avantajlar sağladığını tespit ederseniz ve hala patronunuzu rotayı değiştirmeye ikna edemiyorsanız, o zaman yapabileceğiniz farklı bir iş bulmanızı öneririm. SSIS kullanın.

Neredeyse her zaman çoğu yönetici türünden alacağınız cevap, şunun gibi bir şeydir:

“Buna değmez, şimdi çalışıyor ve değişmesi zaman alacak.”

Ve genel olarak, bu geçerlidir. Bununla birlikte, bu her zaman geçerli bir argüman değildir, çünkü “Burada İcat Edilmedi” sendromunu çevreleyen temel sorun, işlerin işe yarayıp yaramadığı değil, aynı zamanda teknolojinin anlamsız bir şekilde yeniden yazılması , şirket saatlerinin boşa harcanması ve önemli değerlerin azaltılmasıdır. teslim edilen üründen.

Ne İcat Edilmediğini Belirlemeniz Gerekiyor Burada, ne yapılması gerektiğine karar vermeden önce gerçekten gerçekleştiğini belirlemelisiniz. Dahili teknoloji bir sebeple yazılmış olabilir .

Teknolojinin Bir Sebep İçin Yeniden Yazıldığını İşaret Ediyor

• Sattığınız teknoloji de üründür . Eğer bir veritabanı satıcısıysanız, MySQL kodunu kullanarak, ne kadar zaman kazandıracak olursa olsun, birçok nedenden dolayı tehlikeli bir fikirdir.
• Dahili teknoloji bakımlıdır ve kullanıma hazır çözümün eksikliklerine etkili bir şekilde cevap verirken, karşılaştırılabilir temel işlevsellik sağlar.
• Teknoloji , tüm geliştirme ekibinin verimliliğini arttırıyor ve yeni geliştiriciler neden kullanımda olduğu konusunda kolayca satılıyor.
• Şirketin diğer dış teknolojileri başarıyla uyguladığı başka örnekler de var .
• OTS çözümü kesilirse veya kırılırsa işiniz derhal ve ciddi şekilde etkilenir .
• İşletme o kadar büyük ki, yüksek kaliteli araçları düşük maliyetle yazma kaynakları var (örneğin, Google 1000 $ / koltuk MS SQL lisansından daha düşük maliyetli bir veritabanı yazabilir)

Başka bir deyişle, ekip, halihazırda çözülmüş problemleri tekrar çözmenin sakıncalarını anlıyor, ancak iş perspektifinden mantıklı bir şekilde istisnalar ortaya koyuyor.

"Burada İcat Edilmedi" işaretleri:

• Her şey dahili gibi görünüyor ve her şeyin bahanesi var: "ah, çok yavaştı", "ah, Microsoft, nefret ediyoruz", "ah, kullanımı gerçekten zor görünüyor" vb.
• Dış teknolojinin kullanıldığı durumlar için, "evet, iyi kokuyor ve sonunda kendi yazımızı yazmayı planlıyoruz " diye duyuyorsunuz .
• Bu bileşenlerin sahiplerinin üzerinde çalışabilecekleri başka işleri yoktur .
• Yeni geliştiricilerin çoğunun geniş kabul görmüş bir beceri seti ile geldiğini görüyorsunuz, ancak iç takımlara geçmeleri çok zaman alıyor.
• Dikkatli bir analizden sonra , "ya devam edilmezse!" De OTS çözümünden bir özel ya da diğer OTS çözümüne geçmenin belirgin olduğu anlaşılıyor. Senaryo asgari işletme etkisine sahip olacak . Örneğin String.Join(), .NET Framework'ten kaldırılmışsa, özel bir StringJoin()yönteme yeniden uygulama önemsiz olacaktır.

Başka bir deyişle, NIH, bir kişinin kendi kodu yerine harici teknolojinin kullanıldığı durumlarda objektif ve gerçekçi kalamamış bir kalıptır.

Teknoloji bir sebepten dolayı yeniden yazıldığında endişelerinizi dile getirmek, üstleriniz tarafından övülmeli ve takdir edilmelidir. Teknoloji uygulandığında dikkatli bir karar verilmiş olmalıydı ve kararın zaman zaman gözden geçirilmesi iş için iyi bir sonuçtu. İşler zaman içinde değişiyor ve geçerli bir noktaya sahip olabilirsiniz. Geçmişte boşa harcanan zaman, anahtarlama için öngörülen maliyetler ve diğer bilgiler hakkında rakamlar sağlayabilirseniz, (teorik olarak) anahtarlama için bir dava açabilirsiniz.

Tecrübelerinize göre, sayılarınızla aynı fikirde olmayabilirler, ancak ne olursa olsun, sizi en azından duymaları gerekir. Saygı kazanmak için zaman alabilir.

Eğer konuşma bile gerçekleştirilemiyorsa, kibar olsanız bile, sadece "Burada İcat Edilmedi" olabilir. Bu durumda, büyük olasılıkla kolayca çözemeyeceğiniz bir kişilik veya politik sorun olabilir. Sürekli olarak yeniden icadıyla ağır şekilde tıkan bir ortamda çalışmak, geliştiriciler ve iş için toksiktir. Çalıştırmak.

(Not: Çoğu şirkette, her zaman bir NIH unsuru vardır, ancak bu kabul edilebilir bir düzeydedir ve kodlarını ve uygulamalarını düzenli olarak gözden geçirdikleri sürece. Uzun vadede hepimiz bir dereceye kadar suçluyuz, ama asla bir sorun haline gelmez.)

Eh, hepsi maliyet / fayda analizi ile ilgili.

SSIS'e yeniden yazarak ne kazanırsınız? Hız? Önemli mi? Bir GUI'de gerçekleştirilen ve herkesin zamanını harcayan bir süreçse, evet, muhtemelen hızlandırmak iyi bir fikirdir, çünkü onu değiştirmek için harcayan para, iş yerine yerine daha mutlu müşteri veya iç çalışan tarafından geri kazanılacaktır. yazılımı bekliyorum. Ama onun gece yarısı saat 12'de başlayıp saat 6'da değil 01: 00'da bitecek olması halinde ... fazla mesele yok. Evet, 6 zamanı daha hızlı ama kimse farkı hissetmeyecek.

Ve patronunun iyi bir noktası var. Microsoft, teknolojilerinin bazılarını terk etme eğilimindedir. VB6, Linq-SQL, ASP classic, COM + ... Bu, açık kaynak kodlu olmayan herhangi bir yazılım (ve güncelleme olmaması durumunda kuruluşunuzun sürdüremeyeceği kadar büyük olan açık kaynaklı yazılım) için bir risktir. Uygulamanızın merkezinde ise, üzerinde sıkı bir kontrol sahibi olmalısınız.

Yazılım tamamen müşteriye değer katmakla ilgili ve risk getirirken fazla fayda sağlamayan teknik gelişme bu rolü gerçekten yerine getirmiyor.

Bir POC (Kavramı Kanıtı) geliştirin ve sonra onu üstünüze çıkarın. POC, teklif ettiğiniz teknolojiyle gerçek bir fayda tespit etmenize yardımcı olmalıdır. O zaman siz ve üstünüz teknolojiden bahsedebilir ve uygulamak için artılar ve eksiler oluşturabilirsiniz.

POC'yi geliştirmek için muhtemelen normal çalışma süresi dışında biraz fazla zaman harcamanız gerekecektir.

SSIS açısından bir not olarak, onu kullandım ve SSIS paketleri geliştirdim. Aslında SSIS paketlerini kullanarak özel bir yükleme işlemini değiştirdik. Bunu ancak gerçek müşteriler yükleme sürelerinden şikayet ettiği için yaptık. SSIS ile yükleme süreleri önemli ölçüde azaldı ve herkes daha mutlu oldu.

SSIS, temelde çok az programlama içeren bir sürükle ve bırak iş akışıdır. Kara kutunun nasıl çalıştığını öğrenmek biraz zaman alıyor, bu yüzden ekibiniz kullanmaya başlarsa bunu dikkate almanız gerekecek.

İyi cevaplar. Kırılmadıysa, tamir etmeyin. Sadece eklerdim

• Performans kaygıları gerçekten doğru olsa da, "olabilir" sözcüğü kırmızı bayraktır. Öncelikle performans teşhisi yapardım, böylece ele almak için herhangi bir kaynak taahhüt etmeden önce performans probleminin ne olduğunu kanıtlayacağım.

• Microsoft'un en son "çözümü" göz önüne alındığında, çok sayıda insanın MS'in bir zamanlar sürdüğü, ancak sonradan kullanımdan kaldırıldığı ve daha sonra desteklendiği kişiler tarafından yakıldığı düşünülmelidir. Yazılımın büyük kodlama olmadan 10 veya 20 yıl çalışmasını istiyorsanız, buna çok dikkat etmeniz gerekir. Şirketimiz bu şekilde ağır yaralandı.

Ciro patronunuz için dikkate alınacak. Bu beceri setine sahip bir programcıya kıyasla SSIS, DBA arenasına giriyor. Uygulamanız SSIS'i ilk dönüşümün ötesinde kullanmıyorsa, onu öğrenmenin ve yeni C # programcılarının hızlanmasını sağlamanın bir anlamı olmadığından emin değilim, çünkü ekibiniz gibi, çoğu kişi bununla ilgili hiçbir deneyime sahip değil.

Patronunuza SSIS’nin, .NET Framework’ten daha eski bir teknoloji katmanı olduğunu, SQL 7.0’ın “Veri Dönüşüm Çerçevesi” olarak köklerine geri döndüğünüze işaret edebilirsiniz.

Patronunuzun bir noktası olabileceği nokta, SSIS'in Microsoft SQL Server'ın Standart ve Kurumsal sürümlerinin yalnızca bir parçası olduğu gerçeğidir; Bu, müşterileriniz için küçük bir işletme senaryosunda uygulamanızın, ADO.NET ile çalışan, ancak bu konuda yapamayan, bu konuda Sql Express (veya MySQL,) ile tamamen iyi olması durumunda, müşterileriniz için oldukça büyük bir değişiklik yığınıdır. SSIS entegrasyonunu kullanın).

Şimdi, tamamen netleşeyim; IMO, NIH neredeyse hiç bir yazılım geliştirme evi için iyi bir şey değil. Sizi bir çok güçlü araç ve hizmetten alıkoyar. Aynı zamanda yüzünde ikiyüzlü; şirketiniz Visual Studio'yu yazdı mı? .NET Framework hakkında nasıl? SQL Server? Pencereler? Hayır. Yazılımınızı zaten sahip olduğunuz araçların ve platformların üzerine inşa edersiniz (ve müşterilerinizi de öyle yaparsınız). Bu nedenle, genel kabul görmüş ve temel faaliyetlerinizi yerine getirmede yararlı olabilecek bir araç görürseniz, onu benimsiyorsunuz ve uygulamanıza devam etmek için gerekli olacak riskle yaşamayı öğreniyorsunuz. Bu araçların sürümleri, hatta onları bile değiştirin. Bulmaman (patronunuz ilk Windows 95/98 veya oralarda üzerinde çalışan yazılım geliştirdi bahis uzunondan önce, 3.0 / 3.1 gibi). Öyleyse, Windows iş istasyonu işletim sistemlerinde yarım düzine sürümünün gelip gittiğini gördü ve yeni platformlarda çalışacak olan yazılımını güncellemesi gerekti ve XP ile resmi olarak EOLed'de başka bir yazılımla karşılaştı. Şikayet edebilir, ancak bu sadece iş yapmanın maliyeti.

Bununla birlikte, bir NIH tutumu, yararlı olarak görülebilen bir teknolojiyi, hatta bir dizi teknolojiyi kabul etmeyi reddetmek zorunda değildir. Bu reddedilmeler tamamen geçerli maliyet-fayda analizlerine dayanabilir. Bir video izleme ve alarm izleme şirketi için çalışıyorum ve günlük olarak çeşitli yeni teknolojileri veya ürünleri destekleme veya desteklememe kararları veriyoruz. Genellikle, yeni bir teknolojiyi kabul etme kararı ve mevcut görüntülenen destekleyici ve alarm yönetimi yazılımı yığınımızla birlikte bir araya getirmenin verdiği acı, öncelikle müşterilerimiz için değerli olan şeylere dayanmaktadır. Geçenlerde yeni bir DVR türüyle büyük bir entegrasyon projesini bitirdim, çünkü var olan en büyük müşterilerimizden biri bu DVR'ye başka bir büyük isimden fakat teknolojik olarak gecikmeli DVR ürününden yükseltme yaptıklarını söyledi. ve bizim yardımımızla ya da yardımı olmadan yaparlar. Öte yandan, yeni üreticileri, hatta büyük ev isimlerini bile düzenli olarak reddediyoruz, çünkü müşterilerimiz onu kullanmıyor ve bize sahip olan birkaç potansiyel müşterisini kaybetse bile, bunu yapmaya başlamanın hiçbir değeri görmüyoruz. Aynı şeyin versiyonumuzu ödemek istiyoruz.

Dönüşümü eski yoldan yazma, kendime SSIS'i öğretme ve ayrıca yararları göstermek / test etmek için yeni bir yol yazmak için zamanım yok (Hiçbirimiz SSIS'i kullanmamıştık, böylece bir süre olacaktı. nasıl kullanılacağını öğrenmek zorundayım.

Bu tür bir problem, değil mi? Diğer insanlardan fikriniz üzerinde üretkenliklerini riske atmalarını istiyorsunuz ve buna değer olduğunu göstermek için uzuv açmaya istekli değilsiniz. Teknik liderlik, fikirlerinizin değerli olduğunu göstermek için itibarınızı veya boş zamanınızı riske atmanızı gerektirir.

Patronun bakış açısından bir şeyler görmeye çalış. Değiştirmeye çalıştığınız işlevsellik, yazılımınızın yaptıklarının temelini oluşturuyor gibi görünmektedir (bkz. "Vidalanmış" yorumu). İyi bir yönetici, asıl işinizi kendi sorumluluğunuzla dış kaynak olarak yaptığınızı bilir. Gelecekte kaybolabilecek bir teknoloji parçasına çiftliği bahis konusunda endişeli. Çekirdek fonksiyonlar söz konusu olduğunda, İcat Yok Burada aslında iyi bir şey.

Hız bir özellikse, işleri hızlandırmak için başka bir yol bulmanız gerekir. Aksi taktirde, hız sizin müşterilerinize göre sizin için daha önemliyse, şunu bırakın ve unutun derim.

“Kırılmamış olanı düzeltmeyin” diye haklı olmakla birlikte, kabul edilen cevaba katılmıyorum.

Kabul edilen cevap, sorunun çözülmediği perspektifinden geliyor. Orta seviye bir yönetimin bakış açısından bu doğrudur. Geliştiricilerin C # içinde bir ETL çözümü oluşturmak ve sürdürmek için harcanan zamana göre kullanım dışı bir çözüm satın almaya kıyasla maliyet analizi yapılacaksa, C # çözümünün yaratılması 3 ila 4 kat daha uzun sürecektir. ve 10 kat daha fazla bakım ve maliyet (numaralar üzerinde referans aradım ama bulamadım).

Şirketin temel yetkinliği olmadığı sürece, C # 'da veri dönüşümlerini yazmak ve sürdürmek için çok az sebep vardır. Ev yapımı çözüm yavaş olacak, hatalar çıkacak (örneğin bozuk veri), son vakalar olacak, ETL sınıfları arasında çok az yeniden kullanım olacak ve kırılgan olacaktır. Dürüst olmak gerekirse, hangi geliştirici günlerini ETL'yi C # ile yazmak ve sürdürmekle geçirmek istiyor? Yaptım. Bu bir saçmalık. Bu, yaratıcı işten olabildiğince uzağınızda.

İşletmesi ETL olan bir şirket olan Informatica gibi bir araç kullanın. Bu problemi 15 yıldan fazla bir süredir çalışıyorlar. Çözdüler. Araçları sürükle ve bırak, performans gibi yeniden kullanılabilirlik yerleşiktir. Çoğu kimse (yani geliştiricilerin de yok) Informatica araçlarıyla ETL oluşturabilirsiniz. Informatica satmaya çalışmıyorum, herhangi bir araç kullanmıyorum. Sadece tekerleği yeniden icat etmeyin.

Uzun vadede Informatica gibi bir araç satın almak veya SSIS kullanmak, şirketi uzun vadede potansiyel olarak milyonlarca tasarruf edecek. Ve hepsinden önemlisi, ETL'yi sürdürmek zorunda kalmayacak veya kırıldığı zaman bunun sorumluluğunu almayacaksınız.

Daha önce basit görevleri yapmak için SSIS'i denedim.

Çok can sıkıcı olabilir, çünkü basit görevler düşük ila orta seviye karmaşıklık diyagramları doğurur (hayır, diyagramlar dışında "kodlamanın" başka yolu yoktur). Ve kaynak kontrol sorunları Jim'in cevabından habersiz olduğumu gösterdi.

Yan problem: Bu yüzden, hızlandırmak için resim yığınlarınız için işlemlerin büyüklüğünü azaltmanızı öneriyorum. Diyelim ki, her 800 kamera yerine her 800. Bu işlemi desteklemek için gereken G / Ç'nin boyutunu azaltabilir.