क्या प्रोग्रामर को SSIS का उपयोग करना चाहिए, और यदि हां, तो क्यों? [बन्द है]


94

.NET डेवलपर के रूप में, किन कारणों से मुझे कोड लिखने पर SSIS पैकेज पसंद करने चाहिए? हमारे पास वर्तमान में काम करने वाले उत्पादन में एक टन पैकेज है, और वे दोनों "राइट" (शायद।)? और बनाए रखने के लिए दुःस्वप्न हैं। प्रत्येक पैकेज उन बिंदुओं पर मिश्रित C ​​# और VB.NET स्क्रिप्ट के साथ बहुरंगी स्पेगेटी के कटोरे की तरह दिखता है जहां अमूर्तता टूट जाती है। यह पता लगाने के लिए कि प्रत्येक "एक्सक्यूट एसक्यूएल टास्क" या "फॉरचून लूप" क्या करता है, मुझे शापित चीज़ पर डबल क्लिक करना होगा और कई टैब में बिखरे हुए शाब्दिक मूल्यों और अभिव्यक्तियों के पेड़ के माध्यम से ब्राउज़ करना होगा।

मैं खुले विचारों वाला हूं, इसलिए मैं यह जानना चाहूंगा कि क्या कोई अन्य अच्छा डेवलपर एसएसआईएस को सिर्फ कुछ कोड लिखने से अधिक उत्पादक लगता है। यदि आप SSIS को अधिक उपयोगी पाते हैं, तो कृपया मुझे बताएँ।


4
पता नहीं यह कैसे होता है, लेकिन SSIS डेटा वेयरहाउस बनाने के लिए लिखे गए किसी भी मैनुअल कोड की तुलना में बहुत तेज है। यह काम के लिए बनाया गया एक उपकरण है - बाल पैकेज में कार्यों को तोड़ने का प्रयास करें जो एक मास्टर पैकेज से निष्पादित होते हैं
श्री शौब्स

1
इसी तरह के एक प्रश्न का लिंक: stackoverflow.com/q/690123/327165
Ilya Berdichevsky

5
बस इसी के साथ आया। मैं कुछ समस्याग्रस्त SSIS पैकेजों को बनाए रखने के लिए काम कर रहा हूं और उनमें से उपयोगी कार्य को C # प्रोग्राम में निकालने के लिए एक डिकम्पॉइलर लिखा है। code.google.com/p/csharp-dessist
टेड स्पेन्स

5
मेरे अनुभव से, यदि आप "लंबी" और / या "जटिल" धारियों या कई लिपियों में एसएसआईएस दर्दनाक हो सकते हैं। कंसोल ऐप को डीबग करना आसान है। SSIS में, आप अपनी स्क्रिप्ट को अपने आप डिबग नहीं कर सकते। स्क्रिप्ट के कारण उत्पन्न त्रुटि संदेश गुप्त हैं और आप सटीक लाइन नहीं देख सकते हैं जो त्रुटि का कारण बनी। IMO, यदि परियोजना की जरूरतों को मानक SSIS घटकों के साथ पूरा किया जा सकता है, तो SSIS जाने का रास्ता हो सकता है। लेकिन, इसके लिए आपको SSIS घटकों की सीमाओं को जानना होगा। Eg.This वीडियो आपको दिखाता है कि "मेल काम क्यों भेजें" लगभग बेकार है - youtube.com/watch?v=IlUzkMPYDSk
स्टीम

3
इस प्रश्न के 7 उत्तर हैं, इसलिए इसने बहस, तर्क, मतदान या विस्तारित चर्चा को हल नहीं किया। इसे खुला क्यों नहीं रखा?
माइकल फ्रीजिम

जवाबों:


94

मैं एक बड़े डेटा वेयरहाउस और क्यूब को बनाए रखने और प्रबंधित करने के लिए हर दिन SSIS का उपयोग करता हूं। मैं दो साल से 100% बिजनेस इंटेलिजेंस और डेटा वेयरहाउसिंग कर रहा हूं। इससे पहले मैं 10 के लिए .NET एप्लीकेशन डेवलपर था।

SSIS का मान डेटा को एक सीमित स्थान से दूसरे स्थान पर ले जाने के लिए एक वर्कफ़्लो इंजन के रूप में होता है, शायद कुछ सीमित परिवर्तन और रास्ते में सशर्त शाखाएं। यदि आपके पैकेज में बहुत अधिक स्क्रिप्ट है तो आपकी टीम गलत कार्यों के लिए SSIS का उपयोग कर रही है या SQL के साथ सहज नहीं है या उसने प्रचार में खरीदा है। SSIS पैकेज डीबग करना बहुत कठिन है। स्क्रिप्ट घटक एक पूर्ण दुःस्वप्न हैं और इसका उपयोग केवल स्वरूपण, लूपिंग या अंतिम उपाय के रूप में किया जाना चाहिए।

  1. अपने पैकेज को सरल, sql कार्यों और डेटा प्रवाह कार्यों को रखें।
  2. SSIS के बाहर जितना संभव हो उतना काम करें, अधिमानतः SQL में
  3. एक वैश्विक दायरे में अपने चर रखें
  4. अपनी SQL को चर या स्टोर प्रक्रियाओं में रखें, कभी भी इन-लाइन न करें
  5. अपने चर मूल्यों को एक कॉन्फ़िगरेशन स्टोर में रखें, अधिमानतः एक SQL डेटाबेस

1
एसएसआईएस के साथ होने वाली परेशानी के साथ, मैंने और अधिक पक्षपाती जवाब दिया होगा (जैसे कि यदि आप मेरे प्रश्न की टोन से नहीं बता सकते हैं :))। अच्छा जवाब, केविन।
चार्ल्स

6
2002 में रिलीज़ होने पर आपने 10 साल तक .NET के साथ कैसे काम किया?
ब्रैडी होल

7
[उद्धरण] माइक्रोसॉफ्ट ने 1990 के दशक के उत्तरार्ध में .NET फ्रेमवर्क पर विकास शुरू किया था जो मूल रूप से नेक्स्ट जनरेशन विंडोज सर्विसेज (NGWS) के नाम से है। 2000 के अंत तक .NET 1.0 के पहले बीटा संस्करणों को [/ उद्धरण] जारी किया गया था, इसी तरह, वह शायद बीटा के साथ काम कर रहा था।
नाइटफ्रॉग

2010 में इस सवाल का जवाब दिया गया था, इसलिए दो साल की बीआई को हटा दें, और फिर आगे 10, 1998, बीटा रिलीज से दो साल पहले का उल्लेख करता है। अन्यथा, अच्छा जवाब! :)
finoutlook

हां, वैश्विक गुंजाइश समझ में आती है। यदि आप इसे स्थानीय बनाते हैं और इसे कहीं और एक्सेस करना चाहते हैं, तो आपको एक समस्या है। आप बस स्थानीय का दायरा वैश्विक में नहीं बदल सकते। आपको इसके बजाय बहुत सारे क्लिक और डिलीट करने होंगे। यदि आपके पास 10-15 स्थान भी हैं, तो यह दर्द बन जाता है।
स्टीम

52

मैंने कई बार SSIS का उपयोग करने की कोशिश की, और उस पर हार मान ली। IMO यह बहुत आसान है बस मुझे C # की आवश्यकता है। SSIS बहुत जटिल है, इसमें बहुत सारे गोचर्स हैं, और यह इसके लायक नहीं है। SSIS सीखने में एक ही समय बिताने की तुलना में C # कौशल में सुधार करने पर अधिक समय बिताना बेहतर है - आपको अपने प्रशिक्षण पर अधिक लाभ मिलेगा।

वीएस समाधान में कार्यक्षमता का पता लगाना और उसे बनाए रखना बहुत आसान है। वीएस के साथ यूनिट परीक्षण आसान है। मुझे बस इतना करने की जरूरत है कि तोड़फोड़ में स्रोत की जांच करें, और यह सत्यापित करें कि यह कैसे लोड किया गया है। इकाई परीक्षण SSIS पैकेज इसे हल्के ढंग से रखने के लिए बहुत शामिल है।

इसके अलावा, ऐसी परिस्थितियां थीं जब एसएसआईएस चुपचाप कुछ पंक्तियों में कुछ स्तंभों को आबाद करने में विफल हो रहा था, बस अपवादों को उठाए बिना उन्हें स्किप कर रहा था। हमने बहुत समय बिताया है और यह पता लगाया है कि क्या चल रहा है। C # में एक वैकल्पिक समाधान विकसित करने में एक घंटे से भी कम समय लगा, और दो साल तक बिना किसी समस्या के काम किया।


आपकी बातों के लिए धन्यवाद एलेक्स। यहाँ एक उदाहरण है जो मुझे लगता है कि एक गोचा हो सकता है - stackoverflow.com/questions/21616435/…
स्टीम

2
क्या सभी सी # / प्रोग्रामिंग विषयों की सूची ईटीएल डेवलपर के पास होनी चाहिए? उदाहरण के लिए। LINQ, SqlDataReader, DataTable आदि मुझे भी लगता है कि SSIS जटिल कार्यों के लिए अच्छा नहीं है। यदि आपके पास एक आसान "कॉपी-पेस्ट" प्रोजेक्ट / कार्य है, तो एसएसआईएस सबसे अच्छा उपकरण हो सकता है।
स्टीम

@blasto क्या आपने राइनो ईटीएल: ayende.com/blog/3102/rhino-etl-2-0
AK

एलेक्स, जेरोम के जवाब ने राइनो ईटीएल का भी सुझाव दिया। यह मुझे अस्पष्ट लगता है। इसलिए, मैं इसे प्रलेखन, समर्थन और ट्यूटोरियल की कमी के लिए उपयोग करने में संकोच करूंगा। इसके अलावा, ऐसा लगता है कि केवल एक देव इस पर काम कर रहा है। यह उपकरण में मेरा आत्मविश्वास कम कर देता है। मैं इसे मज़ाक के लिए या जिज्ञासा से बाहर करने की कोशिश करूँगा, लेकिन मैं इसका उपयोग वास्तविक परियोजना के लिए नहीं कर सकता। धन्यवाद।
स्टीम

अगर कोई राइनो ईटीएल (शुद्ध सी # के साथ) पर एक ट्यूटोरियल चाहता है तो यहाँ एक है - codeproject.com/Articles/34556/Write-ETL-jobs-in-pure-C
स्टीम

14

मेरी राय में - एसएसआईएस केवल ईटीएल संचालन के लिए है और इसमें उस दायरे से बाहर कोई तर्क नहीं होना चाहिए।


8
ETL = एक्सट्रैक्ट ट्रांसफ़र लोड
क्रिस्टोफ

3
मुझे लगता है कि बहुत सुंदर है। हमारे मामले में, हम मूल्य निर्धारण जानकारी युक्त ईमेल (या SFTP) CSV जैसे सामान करने के लिए SSIS का उपयोग कर रहे हैं। ब्रांचिंग, एम्बेडेड स्क्रिप्ट, आदि बहुत भयानक हैं। अगर बस SSIS के साथ कुछ डेटा को इधर-उधर कर दिया जाए, तो शायद यह इतना बुरा नहीं होगा।
चार्ल्स

1
मुझे लगता है कि आपके उत्तर में कुछ और गहराई हो सकती है।
स्टीम

3
क्या ETL में T कुछ तर्क शामिल नहीं कर सकता है? बस एक विचार ...
cs0815

यदि यह केवल डेटा को आकार देने / मार्ग से संबंधित है, तो सुनिश्चित करें। लेकिन मैं किसी भी व्यावसायिक तर्क से बचूंगा।
क्रिस्टोफ

11

मुझे ऐसी परियोजना पर काम करने का दुर्भाग्यपूर्ण अनुभव था, जहां हमने सोचा था कि एसएसआईएस कई स्रोतों से डेटा एकत्र करने और संयोजित करने के लिए एक अच्छा पर्याप्त समाधान होगा। दुर्भाग्यपूर्ण बात यह थी कि इसने पहली बार बहुत अच्छा काम किया लेकिन फिर आवश्यकताएं बदल गईं और हमें (अंततः) एहसास हुआ कि यह गलत उपकरण था।

शायद हम इसे गलत तरीके से इस्तेमाल कर रहे थे, लेकिन हमें बहुत कठिनाई हुई अगर हमने कभी अपना स्कीमा बदला और हमने अंततः ऐसा करने के लिए C # में एक कस्टम टूल लिखने के लिए सामने के छोर से अपनी ORM परिभाषाओं का फिर से उपयोग किया। क्योंकि हमारे पास पहले से ही डेटामॉडल था यह आश्चर्यजनक रूप से आसान था। जाहिर है YMMV और मैं किसी भी तरह से SSIS विशेषज्ञ नहीं हैं, लेकिन इस मामले में SSIS ने बहुत सारे डुप्लिकेट काम और सिरदर्द पैदा किए जब सिर्फ हमारी आस्तीन और 'हैंडकोडिंग' को रोल करना यह अपेक्षा से अधिक आसान था।

इसलिए मैं SSIS पर विचार करते समय लचीलेपन के बारे में बहुत सोचता हूँ।


7
मैं उन्हीं भावनाओं में से कुछ साझा करता हूं। कोड को रिफलेक्टर करना आसान है ... विजुअल डीएसएल के साथ ऐसा नहीं है।
चार्ल्स

ल्यूक, क्या आप हमें अपनी परियोजना आवश्यकताओं की रूपरेखा दे सकते हैं? धन्यवाद।
स्टीम

@blasto हम कई डेटाबेस से डेटा को एकीकृत करने और विभिन्न प्रणालियों (अनिवार्य रूप से सीआरएम डेटाबेस) से डेटा को मर्ज करने के लिए संभाव्य स्ट्रिंग मिलान उपयोगिताओं में निर्मित कुछ का उपयोग करने की कोशिश कर रहे थे। यह 5 + साल पहले था इसलिए मुझे सभी विवरण याद नहीं हैं।
ल्यूक

यदि आप एक .net दुकान हैं और डेटा वेयरहाउसिंग उद्देश्यों के लिए डेटा ले जाने में शामिल हैं, तो SSIS केवल तभी आपकी मदद करेगा जब आप इसे अच्छी तरह से जान पाएंगे। मैंने कई लोगों को देखा है जो .net गुरु हैं, लेकिन SSIS को पूरी तरह से समझने में असफल रहते हैं (और मैं उन्हें दोष नहीं देता)। SSIS को निश्चित रूप से एक ऐसे व्यक्ति की आवश्यकता है जो इसे अच्छी तरह से जानता हो अन्यथा आप लेखन पैकेजों को समाप्त कर देंगे जो कि अक्षम हैं और सही काम नहीं कर सकते हैं।
rvphx

6

SSIS का अपना स्थान है, और यह स्थान सामान्य प्रोग्रामिंग या संग्रहीत प्रक्रियाओं के प्रतिस्थापन के रूप में नहीं है। यह ETL स्कूल (एक्सट्रेक्ट, ट्रांसफॉर्म और लोड) से आता है और यहीं इसका स्ट्रेन्थ है।

पुराना नाम (DTS, डेटा ट्रांसफ़ॉर्मेशन सर्विसेज) और नया नाम (SSIS, Sql Server इंटीग्रेशन सर्विसेज) दोनों स्पष्ट करते हैं कि यह SQL सर्वर डेटाबेस को बड़ी प्रक्रियाओं में एकीकृत करने के लिए डेटा में हेरफेर करने के लिए डिज़ाइन की गई सेवा (या सेवाओं का सेट) है।


मैं नहीं देखता कि इस उत्तर को कितने उत्थान मिले। यह उल्लेख नहीं करता है कि SSIS आपको प्रोग्रामिंग भाषा की शक्ति क्यों नहीं दे सकता है। मेरे लिए इसका कोई अर्थ नहीं है। एक उदाहरण जहां SSIS प्रोग्रामिंग लैंग से मेल नहीं खाता है वह डीबगिंग है। जाहिर है, SSIS 2012 में परिवर्तन होता है। तो, हो सकता है, बस हो सकता है, उपकरण अधिक प्रोग्रामर फ्रेंडली बनने के रास्ते पर है।
स्टीम

>> एक उदाहरण जहां SSIS प्रोग्रामिंग लैंग से मेल खाने में विफल रहता है ... मैं मानता हूं-यह प्रोग्रामिंग लैंग्वेज नहीं है। यह एक सभ्य ईटीएल उपकरण है।
डेव

4

यदि आप अपने डेटा को प्रोग्रामेटिक रूप से स्थानांतरित करना चाहते हैं, तो आप राइनो ईटीएल को देखना चाहते हैं।

मैं अपने स्वयं के ढांचे पर काम कर रहा हूं, धाराप्रवाह ईटीएल , क्योंकि मैं एसएसआईएस को विकास से संबंधित सरल डेटा कार्यों के लिए थोड़ा सा शामिल करता हूं, जैसे सीएसवी फ़ाइल से यूनिट परीक्षण डेटा लोड करना।


राइनो ईटीएल अस्पष्ट है और एसओ पर अब तक केवल 24 प्रश्न हैं - stackoverflow.com/questions/tagged/rhino-etl । मुझे लगता है कि ईटीएल के लिए सी # काफी अच्छा होगा, अगर आपके पास ज्ञान और अनुभव है।
स्टीम

1
क्या राइनो ईटीएल के लिए कोई लोकप्रिय विकल्प हैं?
स्टीम

3

SSIS एक कार्यक्रम नहीं है। SSIS में बनाने के लिए बहुत से थिग्नेन्स तेज़ होते हैं, और आपको व्यवस्थापक के रूप में बहुत अच्छी विस्तृत प्रगति और त्रुटि की जानकारी मिलती है - जो कि SSIS को हल करने के लिए परिदृश्य में बहुत अच्छी हो सकती है, क्योंकि कभी-कभी चीजें गलत हो जाती हैं और व्यवस्थापक को बहुत अधिक की आवश्यकता होती है जानकारी।

कहा जा रहा है कि, SSIS वास्तव में इतना उपयोगी नहीं है कि यदि आपके पास सामान स्वयं edxplanatory नहीं है - वे किसी चीज के लिए हैं, सामान्य प्रोग्रामिंग में बहुत अधिक हो जाना उन्हें बेकार बनाता है।


2
क्या आप हमें एक उदाहरण दे सकते हैं कि SSIS एक परिदृश्य में विकास को कैसे तेज कर सकता है और दूसरों में धीमा कर सकता है?
स्टीम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.