Haruskah programmer menggunakan SSIS, dan jika demikian, mengapa? [Tutup]

Sebagai pengembang .NET, untuk alasan apa saya lebih memilih paket SSIS daripada menulis kode? Kami memiliki banyak paket dalam produksi di mana saya saat ini bekerja, dan mereka adalah mimpi buruk untuk "menulis" (mungkin menggambar?) Dan mempertahankannya. Setiap paket tampak seperti semangkuk spageti warna-warni dengan skrip C # dan VB.NET bercampur di titik-titik di mana abstraksi rusak. Untuk mengetahui apa yang masing-masing "Jalankan Tugas SQL" atau "Loop Selamanya", saya harus mengklik dua kali benda terkutuk itu dan menelusuri pohon nilai dan ekspresi literal, yang tersebar di banyak tab.

Saya berpikiran terbuka, jadi saya ingin tahu apakah ada pengembang bagus lainnya yang menganggap SSIS lebih produktif daripada hanya menulis beberapa kode. Jika menurut Anda SSIS lebih produktif, beri tahu saya alasannya.

Saya menggunakan SSIS setiap hari untuk memelihara dan mengelola gudang data dan kubus yang besar. Saya telah 100% intelijen bisnis dan pergudangan data selama dua tahun. Sebelumnya saya adalah seorang pengembang aplikasi .NET selama 10 tahun.

Nilai SSIS adalah sebagai mesin alur kerja untuk memindahkan data dari satu tempat ke tempat lain dengan mungkin beberapa transformasi terbatas dan percabangan bersyarat di sepanjang jalan. Jika paket Anda berisi banyak skrip maka tim Anda menggunakan SSIS untuk tugas yang salah atau merasa tidak nyaman dengan SQL atau telah membeli hype. Paket SSIS sangat sulit untuk di-debug. Komponen skrip adalah mimpi buruk absolut dan harus digunakan hanya untuk pemformatan, perulangan, atau sebagai upaya terakhir.

1. Buat paket Anda tetap sederhana, tugas sql, dan tugas aliran data.
2. Lakukan pekerjaan sebanyak mungkin di luar SSIS, sebaiknya di SQL
3. Pertahankan variabel Anda dalam satu cakupan global
4. Simpan SQL Anda dalam variabel atau prosedur penyimpanan, jangan pernah sejalan
5. Simpan nilai variabel Anda di penyimpanan konfigurasi, sebaiknya database SQL

Saya mencoba menggunakan SSIS beberapa kali, dan menyerah. IMO jauh lebih mudah untuk melakukan semua yang saya butuhkan di C #. SSIS terlalu kompleks, memiliki terlalu banyak gotcha, dan itu tidak sepadan. Jauh lebih baik menghabiskan lebih banyak waktu untuk meningkatkan keterampilan C # daripada menghabiskan waktu yang sama untuk mempelajari SSIS - Anda akan mendapatkan lebih banyak keuntungan dari pelatihan Anda.

Juga menemukan dan memelihara fungsionalitas dalam solusi VS jauh lebih mudah. Pengujian unit dengan VS itu mudah. Yang perlu saya lakukan adalah memeriksa sumber di Subversion, dan memverifikasi bagaimana sumber itu dimuat. Paket SSIS pengujian unit sangat terlibat untuk membuatnya lebih ringan.

Selain itu, ada situasi ketika SSIS secara diam-diam gagal mengisi beberapa kolom di beberapa baris, hanya melewatinya tanpa memunculkan pengecualian. Kami menghabiskan banyak waktu untuk memecahkan masalah dan mencari tahu apa yang sedang terjadi. Mengembangkan solusi alternatif dalam C # membutuhkan waktu kurang dari satu jam, dan bekerja tanpa masalah selama dua tahun.

Menurut pendapat saya - SSIS hanya untuk operasi ETL dan tidak boleh mengandung logika di luar cakupan tersebut.

Saya memiliki pengalaman malang mengerjakan sebuah proyek di mana kami pikir SSIS akan menjadi solusi yang cukup baik untuk mengumpulkan dan menggabungkan data dari beberapa sumber. Hal yang disayangkan adalah itu berfungsi dengan baik pada awalnya tetapi kemudian persyaratan berubah dan kami (akhirnya) menyadari bahwa itu adalah alat yang salah.

mungkin kami hanya menggunakannya secara tidak benar tetapi kami mengalami banyak kesulitan jika kami pernah mengubah skema kami dan akhirnya kami hanya menggunakan kembali definisi ORM kami dari ujung depan untuk menulis alat khusus di C # untuk melakukan ini. Karena kami sudah memiliki model data, ini sangat mudah. jelas YMMV dan saya sama sekali bukan ahli SSIS, tetapi dalam kasus yang satu ini SSIS menyebabkan banyak pekerjaan duplikat dan sakit kepala ketika hanya menyingsingkan lengan baju dan 'handcoding' itu lebih mudah dari yang diharapkan.

Jadi saya akan banyak memikirkan tentang fleksibilitas ketika mempertimbangkan SSIS.

SSIS memiliki tempatnya, dan tempat itu bukanlah pemrograman umum atau sebagai pengganti prosedur tersimpan. Itu berasal dari sekolah ETL (Ekstrak, Transformasi, dan Muat) dan di situlah kekuatannya berada.

Nama lama (DTS, Layanan Transformasi Data) dan nama baru (SSIS, Layanan Integrasi Server Sql) keduanya menjelaskan bahwa ini adalah layanan (atau kumpulan layanan) yang dirancang untuk memanipulasi data untuk mengintegrasikan database SQL Server ke dalam proses yang lebih besar.

Jika Anda ingin memindahkan data Anda secara terprogram, Anda mungkin ingin melihat Rhino ETL.

Saya juga mengerjakan kerangka kerja saya sendiri, Fluent ETL , karena menurut saya SSIS agak terlalu rumit untuk tugas data sederhana yang terkait dengan pengembangan, seperti memuat data pengujian unit dari file CSV.

SSIS bukanlah program. Banyak hal yang lebih cepat dibuat di SSIS, dan Anda mendapatkan kemajuan mendetail yang sangat bagus dan informasi kesalahan sebagai admin - yang bisa sangat bagus dalam skenario SSIS yang dimaksudkan untuk diselesaikan, karena terkadang ada yang salah dan admin membutuhkan banyak informasi.

Yang sedang berkata, SSIS tidak terlalu berguna jika Anda tidak memiliki barang-barang itu sendiri edxplanatory - mereka dimaksudkan untuk sesuatu, memasukkan terlalu banyak ke dalam pemrograman umum membuat mereka sial.