Departemen saya berspesialisasi dalam mengonversi data pelanggan ke dalam skema basis data kami sehingga mereka dapat menggunakan perangkat lunak kami.

Saat ini, kami memiliki aplikasi C # yang membutuhkan IDataReader(99% dari waktu itu SqlDataReader), melakukan pembersihan dan pemetaan, memasukkannya ke dalam DataRowobjek, dan kemudian menggunakan a SqlBulkCopyuntuk memasukkannya ke dalam basis data kami.

Kadang-kadang (terutama ketika database sumber berisi gambar sebagai varbinaryobjek), proses ini benar-benar dapat menghambat dengan transfer SQL dari server ke aplikasi untuk saat itu berbalik dan kembali ke server.

Saya merasa bahwa jika kita menulis ulang beberapa konversi sebagai paket SSIS, hal itu dapat mempercepat banyak hal. Namun stonewall terbesar yang terus saya temui adalah ketika bos saya, dalam mode Not Invented Here , mundur dan berkata, "Bagaimana jika Microsoft menjatuhkan dukungan untuk SSIS? Kami akan memiliki semua kode usang ini dan kami akan mengacaukannya."

Ini bukan pertama kalinya saya menekan "Bagaimana jika mereka menghapus fitur itu ...?" jawaban dari bos saya. Saya tidak punya waktu untuk menulis konversi dengan cara lama, belajar sendiri SSIS, dan juga menulis itu cara baru untuk menunjukkan / menguji manfaat (Tidak ada dari kita yang menggunakan SSIS sehingga akan ada periode di mana kita akan harus belajar cara menggunakannya).

Apa yang harus saya lakukan dalam situasi ini? Berhenti mendorong teknologi baru? Tunggu sampai dia keluar dari departemen (saya orang nomor dua di departemen setelah dia, tapi bisa bertahun-tahun sebelum dia berhenti / pensiun)? Temukan cara baru untuk membuatnya berhenti takut pada alat pihak ke-3?

Saya akan mengambil celah ini dari sudut pandang manajerial, tetapi perlu diingat bahwa saya sadar saya tidak memiliki semua detail. Saya akan meringkas apa yang saya lihat:

1. Pengembang tingkat menengah, kami akan memanggilnya "Scott", merekomendasikan penulisan ulang kode warisan ke dalam SSIS untuk meningkatkan kinerja ProcessA proses penting.
2. ProcessA saat ini berperilaku dalam keadaan berfungsi tanpa masalah utama yang diketahui.
3. ProcessA ditulis dengan alat milik menggunakan pengetahuan umum atau berpotensi suku untuk mempertahankan.
4. Rekomendasi untuk menulis ulang akan membutuhkan alat baru untuk mendukung.
5. Staf saat ini tidak memiliki pengalaman / pengetahuan yang terdokumentasi dengan alat-alat baru.
6. Alat baru adalah pengganti yang relatif baru untuk alat yang lebih lama, dan dukungan untuk alat ini dapat berubah secara wajar dalam 4 kuartal bisnis.

Dari perspektif ini, yang saya lihat adalah pengeluaran besar-besaran dari pihak perusahaan untuk memperbaiki proses yang tidak rusak . Dari sudut pandang teknis saya bisa melihat daya tariknya, tetapi ketika Anda langsung melakukannya, tidak masuk akal secara bisnis untuk melakukan perubahan ini. Jika Anda memiliki staf yang siap dengan pengalaman yang terdokumentasi dengan SSIS dan tolok ukur untuk menunjukkan peningkatan besar pada proses ini (perlu diingat, peningkatan besar-besaran HARUS menyamakan dengan $$$), hasilnya mungkin sedikit berbeda. Namun seperti sekarang, saya harus setuju dengan manajemen (di suatu tempat pohon baru saja mati).

Jika Anda ingin mendorong adopsi SSIS dan berpotensi mengarah ke refactor ini, Anda perlu mendapatkan pengalaman dan pelatihan ini dengan proyek-proyek yang lebih kecil dan kurang penting. Berikan tolok ukur dan dukungan untuk SSIS, dan pastikan bahwa semua infrastruktur dan dukungan sudah ada sebelum manajemen bahkan akan mempertimbangkan untuk melakukan perubahan. Setelah Anda memiliki alat yang digunakan di tempat lain, orang-orang di tim berpengalaman dengan penggunaannya, dan faktor "kenyamanan" bisnis yang dukungannya tidak akan mengubah dan mencabut segalanya, Anda akan lebih mungkin untuk mempengaruhi seseorang ke sudut pandang Anda. Tanpa itu, Anda menggonggong pohon yang salah dengan argumen itu.

Meski terdengar bodoh, terkadang cara "terbaik" bukan cara terbaik.

Sunting: Menanggapi beberapa pembaruan terhadap pertanyaan, saya akan memposting sedikit modifikasi pada jawaban saya.

Jika prosesnya mengalami semacam kesulitan, menulis ulang itu masih akan menjadi usaha yang mahal. Anda mungkin ingin mempertimbangkan berapa biaya fine-tuning kode yang ada terhadap penulisan ulang paket. Pertimbangkan dampaknya tidak hanya pada perangkat lunak tetapi juga pada proses antarmuka manusia. Ketika mencoba membuat buy-in manajemen untuk menulis ulang, itu akan selalu tergantung pada uang. Kecuali Anda dapat menunjukkan bahwa kesulitan saat ini adalah biaya uang sekarang atau akan menjadi besar secara agregat, manajemen masih tidak akan melihat manfaatnya. Biaya ini mungkin belum tentu bersifat finansial. Jika perlambatan kompromi sistem menyebabkan downtime, memperkenalkan vektor intrusi, atau gejala "sulit untuk diukur" lainnya, Anda mungkin perlu menemukan cara untuk menerjemahkan masalah itu menjadi setara risiko moneter. Vektor intrusi, misalnya, dapat menyebabkan gangguan yang dapat menyebabkan data hilang, dicuri, atau rusak. Perusahaan dapat kehilangan reputasi atau mungkin gagal dalam audit keamanan yang diperlukan. Kuncinya adalah membuat manajer yang bersangkutan mengenali manfaat perubahan yang dapat diukur.

Breaking Things Is Skill

Saya telah bekerja di terlalu banyak tempat yang menganut argumen "jika tidak rusak" sampai-sampai mereka gagal berinovasi, dan ketika mereka akhirnya dipaksa untuk berinovasi mereka bereaksi berlebihan dengan mengubah segalanya . Hanya karena mereka tidak memiliki pengalaman memecahkan barang .

Dibutuhkan kedewasaan, keterampilan, dan pengalaman untuk memecahkan banyak hal.

Tim pengembang yang selalu bermain aman adalah yang termudah untuk dilampaui oleh pesaing. Hanya tim yang telah gagal, melakukan kesalahan, dan hal-hal yang rusak yang dapat benar-benar melakukan penilaian risiko yang jujur.

Menjaga Status Quo

Meskipun benar, sistem saat ini memenuhi persyaratan bisnis saat ini. Itu tidak benar untuk perubahan di masa depan yang tidak terduga untuk persyaratan tersebut. Seperti pepatah lama mengatakan "keberuntungan lebih memilih yang dipersiapkan".

Pertanyaan ini tidak ada hubungannya dengan SQL atau kinerja. Ini tentang mengajukan pertanyaan, "adakah cara yang lebih baik?" dan tidak takut untuk mencoba alternatif.

Bos Anda menderita kasus Keeping The Status Quo .

Suku Maya

Tidak ada yang benar-benar berfungsi dengan sempurna.

Bangsa Maya terus menanam makanan mereka di sisi gunung. Sampai semua nutrisi tersapu, dan mereka tidak punya cara untuk memberi makan orang-orang mereka. Mereka terus melakukan hal-hal dengan cara yang sama sampai semuanya terlambat.

Dengan asumsi Anda akan punya waktu untuk memperbaiki masalah ketika masalah muncul dengan sendirinya adalah kesalahan.

Apa yang harus dilakukan?

Bos Anda menderita kasus pengondisian. Orang yang menerima status quo sering melakukannya, karena mereka tidak memiliki kemampuan untuk membuat keputusan yang sulit. Saat dihadapkan dengan tantangan, mereka akan cenderung memilih opsi yang paling dekat dengan apa yang mereka kenal.

Ketakutan baginya adalah motivasi besar. Ketakutan akan kondisi yang tidak diketahui atau berubah mengguncang perspektifnya tentang apa status quo. Ia akan cenderung mencoba dan mengembalikan kondisinya kembali normal secepat mungkin.

Anda perlu mempresentasikan ide dengan cara yang tidak bertentangan. Cobalah untuk menemukan titik temu antara apa yang ingin Anda lakukan dengan apa yang sudah menjadi status quo. Sajikan argumen yang mengurangi rasa takutnya akan perubahan, dan tawarkan jaminan bahwa Anda ingin menyelesaikan tugas yang tidak akan menyebabkan perubahan signifikan.

Ambil Langkah Bayi

Akan lebih baik untuk menawarkan perubahan yang memindahkan proyek ke arah yang Anda inginkan, tetapi melalui proyek tambahan kecil. Daripada memukul bos Anda dengan pertanyaan besar tentang mendukung SSIS. Tawarkan untuk membuat lapisan pemisahan dalam kode yang memungkinkan Anda untuk menambahkan metode "alternatif" untuk memproses tabel dengan lampiran besar. Anda kemudian dapat melanjutkan untuk merekomendasikan SSIS dengan semua prasyarat yang telah ditambahkan ke proyek. Ini mengurangi risiko yang dipimpikan atasan Anda dengan menerima perubahan.

Ini membutuhkan waktu

Pengalaman saya adalah bahwa pengambil risiko terus bergerak proyek, dan status quo penjaga seperti dinding bata. Kegigihan adalah satu-satunya pilihan Anda untuk menghancurkan penghalang mereka. Berharap untuk tetap mendengar TIDAK atas pertanyaan Anda.

Ketika tiba saatnya untuk berinovasi. Atasan Anda akan menghadap Anda dengan cepat, karena Anda menunjukkan keberanian dalam menghadapi perubahan. Sesuatu yang orang status quo akan cari, dan Anda akan dihargai untuk usaha Anda. Bahkan jika tidak ada pertanyaan Anda sebelumnya yang diterima. Anda akan dengan cepat menjadi aset yang tak tergantikan di perusahaan yang dihadapkan dengan perubahan yang mencakup tidak ada perubahan.

Saya merasa bahwa jika kita menulis ulang beberapa konversi sebagai paket SSIS, itu dapat mempercepat banyak hal. Namun stonewall terbesar yang terus saya temui adalah ketika bos saya, dalam mode Not Invented Here, mendorong balik dan berkata, "Bagaimana jika Microsoft menjatuhkan dukungan untuk SSIS? Kami akan memiliki semua kode usang ini dan kami akan mengacaukannya."

Menurut pendapat saya, skeptisisme tentang SSIS adalah valid.

• Pengembang berpengalaman membenci kotak hitam, dan ada banyak keajaiban yang terjadi di dalam paket SSIS.
• Dukungan kontrol sumber untuk paket SSIS sangat kurang. Menyebarkan dan menggabungkan file SSIS dtsx dapat menjadi mimpi buruk jika paket dtsx Anda tidak cukup modular.
  • Sebaliknya, aplikasi konsol C # sangat transparan. Anda selalu dapat mengikuti kode untuk mencari tahu apa yang salah.

Juga, pertimbangkan bahwa atasan Anda ada dalam kesulitan jika terjadi kesalahan.

• Oleh karena itu, ia berhak memiliki pendapat utama / hanya pada masalah ini.

Saya tidak punya waktu untuk menulis konversi dengan cara lama, belajar sendiri SSIS, dan juga menulis itu cara baru untuk menunjukkan / menguji manfaat (Tidak ada dari kita yang menggunakan SSIS sehingga akan ada periode di mana kita akan harus belajar cara menggunakannya).

Apa yang harus saya lakukan dalam situasi ini? Berhenti mendorong teknologi baru? Tunggu sampai dia keluar dari departemen (saya orang nomor dua di departemen setelah dia, tapi bisa bertahun-tahun sebelum dia berhenti / pensiun)? Temukan cara baru untuk membuatnya berhenti takut pada alat pihak ke-3?

Saya sarankan Anda mempelajari SSIS dengan cukup baik sehingga Anda dapat menunjukkan manfaatnya.

Dan jika, setelah belajar sendiri, Anda menemukan bahwa SSIS menawarkan keuntungan yang signifikan atas pendekatan yang lebih "tradisional", dan Anda masih tidak dapat meyakinkan atasan Anda untuk mengubah arah, maka saya sarankan Anda mencari pekerjaan lain di mana Anda dapat gunakan SSIS.

Respons yang hampir selalu Anda dapatkan dari sebagian besar tipe manajer adalah sesuatu seperti:

"Itu tidak layak, itu berfungsi sekarang, dan akan butuh waktu untuk berubah."

Dan secara umum, ini valid. Namun, ini tidak selalu merupakan argumen yang valid, karena masalah inti seputar sindrom "Tidak Diciptakan Di Sini" bukanlah apakah sesuatu berfungsi atau tidak berfungsi, tetapi teknologi itu ditulis ulang tanpa tujuan , membuang-buang waktu perusahaan, dan mengurangi nilai substansial dari produk yang dikirim.

Anda perlu menentukan apakah Not Invented Here benar-benar terjadi sebelum memutuskan apa yang harus dilakukan. Teknologi internal mungkin ditulis karena suatu alasan .

Tanda-tanda bahwa Teknologi Ditulis Ulang karena suatu Alasan:

• Teknologi yang Anda jual juga merupakan produk . Jika Anda adalah vendor database, menggunakan kode MySQL, tidak peduli berapa banyak waktu yang dihemat, adalah ide berbahaya karena berbagai alasan.
• Teknologi internal terpelihara dengan baik dan secara efektif mengatasi kekurangan dari solusi yang ada, sambil tetap menyediakan fungsionalitas dasar yang sebanding.
• Teknologi ini meningkatkan produktivitas seluruh tim pengembangan, dan pengembang baru mudah dijual tentang alasan penggunaannya.
• Ada contoh lain di mana perusahaan telah berhasil mengadopsi teknologi eksternal lainnya .
• Bisnis Anda akan segera dan berdampak serius jika solusi OTS dihentikan atau rusak.
• Bisnis ini sangat besar sehingga memiliki sumber daya untuk menulis alat berkualitas tinggi dengan biaya rendah (misalnya, Google mungkin dapat menulis database yang harganya kurang dari $ 1000 / kursi lisensi MS SQL)

Dengan kata lain, tim memahami kelemahan penyelesaian kembali masalah yang sudah dipecahkan, tetapi dengan bijaksana membuat pengecualian di mana itu masuk akal dari perspektif bisnis.

Tanda "Tidak Diciptakan Di Sini":

• Sepertinya semuanya internal , dan ada alasan untuk semuanya: "eh, itu terlalu lambat", "eh, ini Microsoft, kami membenci Microsoft", "eh, sepertinya sangat sulit digunakan", dll.
• Untuk kasus-kasus di mana teknologi eksternal digunakan, Anda mendengar "ya, baik itu bau dan kami berencana untuk menulis sendiri akhirnya ".
• Pemilik komponen tersebut tidak memiliki pekerjaan lain yang dapat mereka kerjakan.
• Anda melihat sebagian besar pengembang baru datang dengan serangkaian keterampilan yang diterima secara luas, tetapi dibutuhkan waktu yang cukup lama bagi mereka untuk meningkatkan kemampuan internal
• Setelah analisis yang cermat, mungkin beralih dari solusi OTS ke solusi kustom atau OTS lainnya di "bagaimana jika itu dihentikan!" Skenario akan memiliki dampak bisnis yang minimal . Misalnya, jika String.Join()dihapus dari .NET Framework, implementasi ulang ke StringJoin()metode kustom akan sepele.

Dengan kata lain, NIH adalah pola gagal untuk tetap objektif dan realistis dalam kasus di mana teknologi eksternal digunakan alih-alih kode sendiri.

Ketika teknologi ditulis ulang karena suatu alasan, mengemukakan kekhawatiran Anda harus dipuji dan dihargai oleh atasan Anda. Seharusnya itu keputusan yang hati-hati ketika teknologi itu diterapkan, dan meninjau ulang keputusan itu kadang baik untuk bisnis. Banyak hal berubah seiring waktu dan Anda mungkin memiliki poin yang valid. Jika Anda dapat memberikan nomor tentang waktu yang terbuang di masa lalu, biaya yang diproyeksikan untuk beralih, dan informasi lainnya, Anda dapat (secara teori) mengajukan alasan untuk beralih.

Pahami bahwa berdasarkan pengalaman Anda, mereka mungkin tidak setuju dengan nomor Anda, tetapi terlepas dari itu, mereka setidaknya harus mendengarkan Anda. Mungkin perlu waktu untuk mendapatkan rasa hormat.

Jika percakapan bahkan tidak dapat diangkat, bahkan jika Anda bersikap sopan, mungkin saja "Tidak Diciptakan Di Sini". Dalam hal ini, kemungkinan besar masalah kepribadian atau politik yang mungkin tidak dapat Anda perbaiki dengan mudah. Bekerja di lingkungan yang sangat macet karena reinvention terus-menerus adalah racun bagi pengembang dan bisnis. Lari.

(Catatan: Di sebagian besar perusahaan, selalu ada unsur NIH, tetapi pada tingkat yang dapat ditoleransi, dan selama mereka secara teratur meninjau kode dan praktik mereka. Dalam jangka panjang kita semua bersalah karenanya sampai taraf tertentu, tetapi itu tidak pernah menjadi masalah.)

Nah, itu semua tentang analisis biaya / manfaat.

Apa yang Anda dapatkan dengan menulis ulang ke SSIS? Kecepatan? Apakah itu penting? Jika ini adalah proses yang dieksekusi dalam GUI dan membuang waktu semua orang, maka ya, itu mungkin ide yang baik untuk mempercepatnya, karena uang yang dihabiskan untuk mengubahnya akan diperoleh kembali oleh pelanggan yang lebih bahagia atau karyawan internal yang melakukan pekerjaan mereka alih-alih menunggu perangkat lunak. Tetapi jika itu adalah batch malam yang dimulai pada jam 12 pagi dan akan berakhir pada jam 1 pagi bukannya jam 6 pagi ... tidak ada gunanya. Ya ini 6 kali lebih cepat tetapi tidak ada yang akan merasakan perbedaannya.

Dan bos Anda memang memiliki poin bagus. Microsoft cenderung mengabaikan beberapa teknologinya. VB6, Linq-to-SQL, ASP classic, COM + ... Ini adalah risiko dengan perangkat lunak non-open source (dan perangkat lunak open-source yang akan terlalu besar untuk dikelola oleh organisasi Anda jika tidak ada pembaruan). Jika ini adalah pusat aplikasi Anda, Anda harus memiliki kontrol ketat terhadapnya.

Perangkat lunak adalah semua tentang menambahkan nilai kepada pelanggan, dan peningkatan teknis yang tidak menghasilkan banyak manfaat saat memperkenalkan risiko tidak benar-benar memenuhi peran itu.

Kembangkan POC (Proof of Concept) dan kemudian demokan ke atasan Anda. POC harus membantu Anda menentukan manfaat nyata dengan teknologi yang Anda usulkan. Kemudian Anda dan atasan Anda dapat berbicara tentang teknologi dan mengembangkan pro dan kontra untuk menerapkannya.

Anda mungkin harus menghabiskan waktu ekstra di luar waktu kerja normal untuk mengembangkan POC.

Sebagai catatan dari sudut pandang SSIS, saya telah menggunakannya dan telah mengembangkan paket SSIS. Kami sebenarnya mengganti proses pemuatan hak milik menggunakan paket SSIS. Kami hanya melakukan ini karena pelanggan sebenarnya mengeluh tentang waktu muat. Waktu pemuatan menurun secara signifikan dengan SSIS dan semua orang menjadi lebih bahagia.

SSIS pada dasarnya adalah alur kerja drag and drop dengan sedikit pemrograman yang terlibat Perlu waktu untuk mempelajari cara kerja kotak hitam, jadi Anda harus mempertimbangkannya jika tim Anda mulai menggunakannya.

Jawaban yang bagus Jika tidak rusak, jangan memperbaikinya. Saya hanya akan menambahkan

• Sementara kekhawatiran kinerja sebenarnya mungkin benar, kata "mungkin" adalah bendera merah. Saya akan melakukan diagnosis kinerja terlebih dahulu, jadi saya akan memiliki bukti tentang apa masalah kinerja itu, sebelum melakukan sumber daya apa pun untuk mengatasinya.

• Ketika mempertimbangkan "solusi" terbaru dari Microsoft, orang harus mempertimbangkan bahwa banyak orang telah dibakar oleh apa yang pernah MS gembar-gemborkan tetapi kemudian ditinggalkan dan kemudian tidak didukung. Jika Anda ingin perangkat lunak berjalan selama 10 atau 20 tahun tanpa pengodean ulang yang besar, Anda harus sangat berhati-hati. Perusahaan kami terluka parah seperti itu.

Pergantian akan menjadi pertimbangan bagi bos Anda. SSIS masuk ke arena DBA dibandingkan dengan seorang programmer yang memiliki keahlian tersebut. Jika aplikasi Anda tidak menggunakan SSIS di luar konversi awal, saya tidak yakin masuk akal untuk mempelajarinya dan mempercepat programmer C # karena seperti tim Anda, sebagian besar tidak memiliki pengalaman dengannya.

Anda bisa menunjukkan kepada atasan Anda bahwa SSIS, pada kenyataannya, adalah lapisan teknologi yang lebih tua dari .NET Framework, jika Anda kembali ke akarnya sebagai "Kerangka Transformasi Data" dari SQL 7.0.

Di mana bos Anda ada benarnya adalah pada kenyataan bahwa SSIS hanya bagian dari versi Standar dan Perusahaan dari Microsoft Sql Server; itu adalah bagian dari perubahan yang agak besar bagi klien Anda untuk dikompromikan, ketika aplikasi Anda, dalam skenario bisnis kecil, mungkin baik-baik saja dengan Sql Express (atau MySQL, dalam hal ini, yang bekerja dengan ADO.NET tetapi tidak bisa gunakan integrasi SSIS).

Sekarang, izinkan saya menjadi sangat jelas; IMO, NIH hampir tidak pernah merupakan hal yang baik untuk rumah pengembangan perangkat lunak. Ini mengunci Anda dari banyak alat dan layanan yang sangat kuat. Itu juga munafik di wajahnya; apakah perusahaan Anda menulis Visual Studio? Bagaimana dengan .NET Framework? Sql Server? Windows? Tidak. Anda membangun perangkat lunak Anda di atas alat dan platform yang sudah Anda miliki (dan begitu juga klien Anda). Oleh karena itu, jika Anda melihat alat yang mendapatkan penerimaan umum, dan yang dapat berguna dalam menjalankan bisnis inti Anda, Anda mengadopsinya, dan Anda belajar untuk hidup dengan risiko bahwa Anda harus mempertahankan implementasi Anda untuk mengikuti yang terbaru versi alat-alat itu, atau bahkan menggantinya. Saya yakin bos Anda pertama kali mengembangkan perangkat lunak untuk berjalan di Windows 95/98 atau sekitar itu (jika tidak lama)sebelum itu, seperti 3.0 / 3.1). Jika demikian, dia melihat setengah lusin versi OS workstation Windows datang dan pergi, dan harus memperbarui perangkat lunaknya untuk berjalan pada platform yang lebih baru, dan dia menghadapi yang lain dengan XP secara resmi EOLed. Sementara dia mungkin mengeluh, itu hanya biaya berbisnis.

Namun, sikap NIH tidak selalu mengikuti penolakan untuk menerima satu, atau bahkan sejumlah, teknologi yang dapat dianggap bermanfaat. Penolakan itu bisa didasarkan pada analisis manfaat-biaya yang valid. Saya bekerja untuk perusahaan pengawasan video dan alarm, dan kami membuat keputusan untuk mendukung atau tidak mendukung berbagai teknologi atau produk baru setiap hari. Biasanya, keputusan untuk menerima teknologi baru, dan kepedihan karena menyatukannya dengan tumpukan perangkat lunak penampil yang didukung dan manajemen alarm kami, didasarkan terutama pada apa nilainya bagi pelanggan kami. Saya baru-baru ini menyelesaikan proyek integrasi besar dengan tipe baru DVR, hanya karena salah satu pelanggan terbesar kami mengatakan mereka meningkatkan ke DVR itu dari nama besar lain tetapi produk DVR yang tertinggal secara teknologi, dan mereka akan melakukannya dengan atau tanpa bantuan kami. Di sisi lain kami secara teratur menolak produsen baru, bahkan nama-nama rumah tangga besar, hanya karena pelanggan kami tidak menggunakannya dan kami melihat tidak ada gunanya mulai menawarkannya, bahkan jika itu kehilangan kami beberapa pelanggan potensial yang memilikinya dan tidak Saya tidak ingin membayar versi kami untuk hal yang sama.

Saya tidak punya waktu untuk menulis konversi dengan cara lama, belajar sendiri SSIS, dan juga menulis itu cara baru untuk menunjukkan / menguji manfaat (Tidak ada dari kita yang menggunakan SSIS sehingga akan ada periode di mana kita akan harus belajar cara menggunakannya).

Itu semacam masalah, bukan? Anda meminta orang lain untuk mempertaruhkan produktivitas mereka atas ide Anda, dan Anda tidak mau mengambil risiko untuk menunjukkan kepada mereka bahwa itu sepadan. Kepemimpinan teknis membutuhkan mempertaruhkan reputasi Anda atau waktu luang Anda untuk menunjukkan bahwa ide-ide Anda layak dimiliki.

Cobalah untuk melihat sesuatu dari sudut pandang atasan Anda. Kedengarannya seperti fungsionalitas yang Anda coba ganti adalah inti dari apa yang dilakukan perangkat lunak Anda (lihat komentar "kacau" -nya). Seorang manajer yang baik tahu bahwa Anda melakukan outsourcing bisnis inti Anda atas risiko sendiri. Dia benar khawatir tentang bertaruh pertanian pada beberapa teknologi yang mungkin hilang di masa depan. Ketika fungsi inti terlibat, Not Invented Here sebenarnya adalah hal yang baik.

Jika kecepatan adalah fitur, Anda harus mencari cara lain untuk mempercepatnya. Kalau tidak, jika kecepatan lebih penting bagi Anda daripada klien Anda, saya katakan jatuhkan dan lupakan.

Meskipun ada manfaat untuk "jangan memperbaiki apa yang tidak rusak" saya tidak setuju dengan jawaban yang diterima.

Jawaban yang diterima datang dari perspektif bahwa masalah tidak rusak. Dari perspektif manajemen tingkat menengah, ini benar. Jika analisis biaya harus dilakukan pada waktu yang dihabiskan oleh pengembang untuk membuat dan memelihara solusi ETL dalam C # dibandingkan dengan membeli solusi out-of-the-box, itu akan menunjukkan solusi C # membutuhkan 3 hingga 4 kali lebih lama untuk membuat dan memelihara dan biaya sebanyak 10 kali lebih banyak (saya mencari referensi pada angka-angka, tetapi saya tidak dapat menemukannya).

Kecuali itu kompetensi inti perusahaan, hanya ada sedikit alasan untuk menulis dan memelihara transformasi data dalam C #. Solusi homegrown akan lambat, akan ada kesalahan (yaitu data korup), akan ada kasus tepi, akan ada sedikit penggunaan kembali antara kelas ETL, dan itu akan rapuh. Jujur, pengembang apa yang ingin menghabiskan hari-harinya menulis dan memelihara ETL dalam C #? Saya sudah melakukannya. Ini omong kosong. Ini tentang pekerjaan kreatif sejauh mungkin.

Gunakan alat seperti Informatica, perusahaan yang bisnisnya ETL. Mereka telah menangani masalah ini selama lebih dari 15 tahun. Mereka telah memecahkannya. Alat mereka seret dan lepas, dapat digunakan kembali adalah built-in, seperti kinerja. Kebanyakan orang (mis. Pengembang tidak memiliki terlalu) dapat membuat ETL dengan toolatic Informatica. Saya tidak mencoba menjual Informatica, gunakan alat apa pun. Hanya saja, jangan menciptakan kembali roda.

Dalam jangka panjang, membeli alat, seperti Informatica atau menggunakan SSIS akan menyelamatkan perusahaan berpotensi jutaan dalam jangka panjang. Dan yang terbaik dari semuanya, Anda tidak harus mempertahankan ETL atau bertanggung jawab atas hal itu ketika rusak.

Saya sudah mencoba SSIS untuk melakukan tugas-tugas sederhana sebelumnya.

Ini bisa sangat menjengkelkan, karena bahkan tugas-tugas sederhana melahirkan diagram kompleksitas tingkat rendah hingga menengah (tidak, tidak ada cara lain untuk "memberi kode" kecuali diagram). Dan masalah kontrol sumber yang ditunjukkan oleh jawaban Jim saya tidak sadar.

Masalah samping: Jadi, untuk mempercepat, saya sarankan kurangi ukuran transaksi untuk gambar Anda. Katakanlah, setiap 800 bukannya 5000 rocords. Itu dapat mengurangi ukuran I / O yang dibutuhkan untuk mendukung transaksi itu.