Programcılar SSIS kullanmalı mı, öyleyse neden? [kapalı]

Bir .NET geliştiricisi olarak, SSIS paketlerini kod yazmak yerine hangi nedenlerle tercih etmeliyim? Şu anda çalıştığım üretimde tonlarca ambalajımız var ve bunlar hem "yazmak" (belki çizmek?) Hem de sürdürmek için bir kabus. Her paket, soyutlamaların bozulduğu noktalarda karıştırılmış C # ve VB.NET komut dosyalarına sahip çok renkli spagetti kasesine benziyor. Her "SQL Görevini Yürüt" veya "Foreach Döngüsü" nün ne yaptığını anlamak için, lanet olası şeyi çift tıklamam ve birden çok sekmeye dağılmış bir dizi değişmez değerler ve ifadeler ağacına göz atmam gerekiyor.

Açık fikirliyim, bu yüzden diğer iyi geliştiricilerin SSIS'i sadece bir kod yazmaktan daha verimli bulup bulmadığını bilmek istiyorum . SSIS'i daha üretken bulursanız, lütfen bana nedenini söyleyin.

Büyük bir veri ambarı ve küpü korumak ve yönetmek için her gün SSIS kullanıyorum. İki yıldır% 100 iş zekası ve veri ambarı yapıyorum. Ondan önce 10 için .NET uygulama geliştiricisiydim.

SSIS'in değeri, verileri bir noktadan diğerine taşımak için bir iş akışı motoru olarak, yol boyunca sınırlı bir dönüşüm ve koşullu dallanma olabilir. Paketleriniz çok sayıda komut dosyası içeriyorsa, ekibiniz SSIS'i yanlış görevler için kullanıyor veya SQL konusunda rahat değil veya yutturmaca satın almış. SSIS paketlerinde hata ayıklamak çok zordur. Komut dosyası bileşenleri mutlak bir kabustur ve yalnızca biçimlendirme, döngü veya son çare olarak kullanılmalıdır.

1. Paketlerinizi basit, sql görevleri ve veri akışı görevleri tutun.
2. SSIS dışında, tercihen SQL'de mümkün olduğunca çok çalışın
3. Değişkenlerinizi tek bir genel kapsamda tutun
4. SQL'inizi değişkenler veya depolama prosedürleri içinde tutun, asla sıralı değil
5. Değişken değerlerinizi bir yapılandırma deposunda, tercihen bir SQL veritabanında tutun

SSIS'i birkaç kez kullanmayı denedim ve vazgeçtim. IMO C # ile ihtiyacım olan her şeyi yapmak çok daha kolay. SSIS çok karmaşık, çok fazla sorun var ve buna değmez. Aynı zamanı SSIS öğrenmek için harcamaktansa C # becerilerini geliştirmek için daha fazla zaman harcamak çok daha iyidir - eğitiminizden çok daha fazla getiri elde edersiniz.

Ayrıca bir VS çözümünde işlevselliği bulmak ve sürdürmek çok daha kolaydır. VS ile birim testi kolaydır. Tek yapmam gereken Subversion'da kaynağı kontrol etmek ve nasıl yüklendiğini doğrulamak. SSIS paketlerinin birim testi, hafifçe söylemek için çok karmaşıktır.

Ayrıca, SSIS'in bazı satırlarda bazı sütunları sessizce doldurmakta başarısız olduğu, istisnaları artırmadan sadece onları atladığı durumlar vardı. Sorun gidermek ve neler olup bittiğini anlamak için çok zaman harcadık. C # ile alternatif bir çözüm geliştirmek bir saatten az sürdü ve iki yıl sorunsuz çalışıyor.

Bana göre - SSIS yalnızca ETL işlemleri içindir ve bu kapsamın dışında hiçbir mantık içermemelidir.

SSIS'in çeşitli kaynaklardan verileri toplamak ve birleştirmek için yeterince iyi bir çözüm olacağını düşündüğümüz bir proje üzerinde çalışırken talihsiz bir deneyim yaşadım. Talihsiz olan şey, ilk başta harika çalışmasıydı, ancak daha sonra gereksinimler değişti ve (sonunda) bunun yanlış araç olduğunu anladık.

belki sadece yanlış kullanıyorduk ama şemamızı değiştirirsek çok zorlandık ve sonunda bunu yapmak için C # ile özel bir araç yazmak için ön uçtan ORM tanımlarımızı yeniden kullandık. Veri modeline zaten sahip olduğumuz için bu şaşırtıcı derecede kolaydı. Açıkçası YMMV ve ben hiçbir şekilde bir SSIS uzmanı değilim, ancak bu durumda SSIS, kollarımızı sıvayıp 'kodlama' yaptığımızda çok sayıda yinelenen işe ve baş ağrısına neden oldu ve bu beklenenden daha kolaydı.

Bu yüzden SSIS'i düşünürken esnekliği çok düşünürdüm.

SSIS'in yeri vardır ve bu yer genel programlama veya saklı yordamların yerine geçme yeri değildir. ETL okulundan (Çıkar, Dönüştür ve Yükle) gelir ve kökeni orasıdır.

Eski ad (DTS, Veri Dönüştürme Hizmetleri) ve yeni ad (SSIS, Sql Sunucu Entegrasyon Hizmetleri), SQL Server veritabanını daha büyük süreçlere entegre etmek için verileri işlemek üzere tasarlanmış bir hizmet (veya hizmetler kümesi) olduğunu açıkça ortaya koymaktadır.

Verilerinizi programlı olarak taşımak istiyorsanız, Rhino ETL'ye bakmak isteyebilirsiniz.

Ayrıca, SSIS'i bir CSV dosyasından birim test verilerini yüklemek gibi geliştirme ile ilgili basit veri görevleri için biraz fazla ilgili bulduğum için kendi çerçevem Fluent ETL üzerinde çalışıyorum .

SSIS bir program değildir. SSIS'de birçok şey yapmak daha hızlıdır ve yönetici olarak çok güzel ayrıntılı ilerleme ve hata bilgileri elde edersiniz - bu, SSIS'in çözmesi gereken senaryolarda çok iyi olabilir, çünkü bazen işler ters gider ve yöneticinin çok şey yapması gerekir. bilgi.

Bununla birlikte, SSIS, kendi kendine açıklayıcı şeylere sahip değilseniz, gerçekten o kadar yararlı değildir - bunlar bir şey içindir, genel programlamaya çok fazla girmek onları iğrenç yapar.