LINQ-to-SQL बनाम संग्रहीत कार्यविधियाँ? [बन्द है]

Question

मैंने StackOverflow ( Beginners Guide to LINQ ) पर यहां "बिगिनर्स गाइड टू लिनक्यू" पोस्ट पर एक नज़र डाली , लेकिन एक अनुवर्ती प्रश्न था:

हम एक नई परियोजना शुरू करने जा रहे हैं, जहाँ हमारे लगभग सभी डेटाबेस ऑप्स काफी सरल डेटा रिट्रीवल होंगे (प्रोजेक्ट का एक और सेगमेंट जो पहले से ही डेटा लिखता है)। इस बिंदु तक हमारी अधिकांश अन्य परियोजनाएं ऐसी चीजों के लिए संग्रहीत प्रक्रियाओं का उपयोग करती हैं। हालाँकि, अगर यह अधिक समझ में आता है तो मैं LINQ-to-SQL का लाभ उठाना चाहूंगा।

तो, सवाल यह है: सरल डेटा पुनर्प्राप्ति के लिए, कौन सा दृष्टिकोण बेहतर है, LINQ-to-SQL या संग्रहीत प्रॉक्सेस? किसी भी विशिष्ट समर्थक या चोर की?

धन्यवाद।

Answer 1

LINQ sprocs के कुछ फायदे:

1. प्रकार की सुरक्षा : मुझे लगता है कि हम सभी इसे समझते हैं।
2. अमूर्त : यह LINQ-to-Entities के साथ विशेष रूप से सच है । यह अमूर्त रूपरेखा भी अतिरिक्त सुधारों को जोड़ने की अनुमति देती है जिसका आप आसानी से लाभ उठा सकते हैं। PLINQ LINQ में मल्टी-थ्रेडिंग सपोर्ट जोड़ने का एक उदाहरण है। इस समर्थन को जोड़ने के लिए कोड परिवर्तन न्यूनतम हैं। यह डेटा एक्सेस कोड करने के लिए बहुत कठिन होगा जो केवल स्पोक कहता है।
3. डिबगिंग समर्थन : मैं प्रश्नों को डीबग करने के लिए किसी भी .NET डीबगर का उपयोग कर सकता हूं। स्प्रोक्स के साथ, आप आसानी से एसक्यूएल को डिबग नहीं कर सकते हैं और यह अनुभव काफी हद तक आपके डेटाबेस विक्रेता से जुड़ा हुआ है (एमएस एसक्यूएल सर्वर एक क्वेरी विश्लेषक प्रदान करता है, लेकिन अक्सर यह पर्याप्त नहीं होता है)।
4. विक्रेता अज्ञेयवादी : LINQ बहुत सारे डेटाबेस के साथ काम करता है और समर्थित डेटाबेसों की संख्या में वृद्धि होगी। डेटाबेस के बीच स्प्रोक्स हमेशा पोर्टेबल नहीं होते हैं, या तो अलग-अलग सिंटैक्स या सुविधा समर्थन के कारण (यदि डेटाबेस सभी स्प्रोक्स का समर्थन करता है)।
5. परिनियोजन : अन्य लोगों ने इसका उल्लेख पहले ही कर दिया है, लेकिन किसी एक असेंबली को तैनात करने की तुलना में स्प्रोक्स का एक सेट तैनात करना आसान है। यह भी # 4 के साथ संबंध रखता है।
6. आसान : आपको डेटा एक्सेस करने के लिए टी-एसक्यूएल सीखना नहीं है, न ही आपको स्प्रोस को कॉल करने के लिए आवश्यक डेटा एक्सेस एपीआई (जैसे ADO.NET) सीखना होगा। यह # 3 और # 4 से संबंधित है।

लाइनक्यू बनाम स्प्रोक्स के कुछ नुकसान:

1. नेटवर्क ट्रैफ़िक : स्प्रोक्स को केवल तार पर स्प्रो-नाम और तर्क डेटा को क्रमबद्ध करने की आवश्यकता होती है, जबकि LINQ पूरी क्वेरी भेजता है। यह वास्तव में बुरा हो सकता है यदि प्रश्न बहुत जटिल हैं। हालाँकि, LINQ का अमूर्त समय के साथ Microsoft को इसमें सुधार करने की अनुमति देता है।
2. कम लचीला : स्प्रोक्स डेटाबेस के फीचर्स का पूरा फायदा उठा सकते हैं। LINQ इसके समर्थन में अधिक सामान्य हो जाता है। यह किसी भी प्रकार की भाषा में अमूर्तता (जैसे C # बनाम कोडांतरक) में आम है।
3. Recompiling : यदि आपको डेटा एक्सेस करने के तरीके में बदलाव करने की आवश्यकता है, तो आपको अपनी असेंबली को फिर से खोलने, संस्करण और फिर से तैयार करने की आवश्यकता है। Sprocs कभी-कभी एक डीबीए को कुछ भी नया करने की आवश्यकता के बिना डेटा एक्सेस रूटीन को ट्यून करने की अनुमति दे सकते हैं ।

सुरक्षा और प्रबंधनीयता एक ऐसी चीज है जिसके बारे में लोग बहस करते हैं।

1. सुरक्षा : उदाहरण के लिए, आप अपने संवेदनशील डेटा को सीधे तालिकाओं तक पहुंच को प्रतिबंधित करके, और एसीएल को स्प्रोक्स पर रख सकते हैं। LINQ के साथ, हालांकि, आप अभी भी तालिकाओं तक सीधी पहुंच को प्रतिबंधित कर सकते हैं और इसके बजाय एक समान अंत प्राप्त करने के लिए अप करने योग्य तालिका विचारों पर ACLs लगा सकते हैं (यह मानते हुए कि आपका डेटाबेस अद्यतन योग्य विचारों का समर्थन करता है)।
2. प्रबंधनीयता : विचारों का उपयोग करने से आपको स्कीमा परिवर्तन (जैसे तालिका सामान्यीकरण) से अपने आवेदन को न तोड़ने के लाभ मिलते हैं। आप अपने डेटा एक्सेस कोड को बदलने की आवश्यकता के बिना दृश्य को अपडेट कर सकते हैं।

मैं एक बड़ा स्पोक लड़का हुआ करता था, लेकिन मैं सामान्य रूप से बेहतर विकल्प के रूप में लिनक्यू की ओर झुकाव करना शुरू कर रहा हूं। यदि कुछ क्षेत्र ऐसे हैं जहाँ स्पार्क्स स्पष्ट रूप से बेहतर हैं, तो मैं शायद अभी भी एक स्पोक लिखूंगा, लेकिन LINQ का उपयोग करके इसे एक्सेस कर सकता हूं। :)

Comments

"LINQ बहुत सारे डेटाबेस के साथ काम करता है" लेकिन LINQTOSQL केवल SQL सर्वर का समर्थन करता है।

— रसेल एचएच

LINQ to Entities MSSQL के अलावा Postgres और MySql के साथ काम करता है। यकीन नहीं हुआ, लेकिन मुझे लगा कि मैंने पढ़ा है कि ऑरेकल के आसपास कुछ था।

— bbqchickenrobot

devart डॉटकनेक्ट में एक ओरेकल चीज़ है, लेकिन यह नरक के रूप में छोटी गाड़ी है। इसके अलावा, मैं डेटाबेस से बाहर डेटा का चयन करने के लिए इसे प्रस्तुत करने के लिए पेश किए गए प्रदर्शन घाटे को प्राप्त नहीं कर सकता (अटैच) भी संभव है, लेकिन यह बल्कि poopey है)

— एड जेम्स

मैंने यहां किसी को कोड पुन: उपयोग का उल्लेख नहीं किया है। आप VB6 या एस्प या फ़ाइल निर्माता प्रो ऐप में आपको फिर से उपयोग नहीं कर सकते। यदि आप डेटाबेस में कुछ डालते हैं तो इसका उपयोग हर किसी के लिए किया जा सकता है। आप इसमें linq के साथ एक dll बना सकते हैं मुझे लगता है लेकिन यह बहुत जटिल और भद्दा imo हो रहा है। एक समारोह या संग्रहित खरीद जोड़ना जिसका पुन: उपयोग किया जा सकता है, बहुत सरल है।

— माइककूल

टीएसक्यूएल में कोड री-यूज की बात करें तो (1) डायनामिक एसक्यूएल का सहारा लिए बिना टेंपरेचर टेबल में स्टोर की गई प्रक्रिया के परिणामों को बचाने की कोशिश करना सौभाग्य है। (२) आपके सभी प्रोक्स / फ़ंक्शंस को व्यवस्थित करने के लिए आप बहुत कुछ नहीं कर सकते हैं; नेमस्पेस तेजी से बंद हो जाता है। (3) आपने एक शक्तिशाली चुनिंदा कथन लिखा है, लेकिन अब आप चाहते हैं कि उपयोगकर्ता उस कॉलम को चुन सके, जो क्रमबद्ध हो जाता है - TSQL में आपको CTE का उपयोग करना पड़ सकता है जो प्रत्येक कॉलम के ऊपर एक पंक्ति_नंबर करता है जिसे क्रमबद्ध किया जा सकता है; LINQ में इसे कुछ ifबयानों के बाद हल किया जा सकता है ।

— स्पेयरबाइट्स 17

Answer 2

मैं आमतौर पर संग्रहीत प्रक्रियाओं में सब कुछ डालने का प्रस्तावक हूं, उन सभी कारणों के लिए जो डीबीए वर्षों से नुकसान पहुंचा रहे हैं। Linq के मामले में, यह सच है कि साधारण CRUD प्रश्नों के साथ कोई प्रदर्शन अंतर नहीं होगा।

लेकिन यह निर्णय लेते समय कुछ बातों को ध्यान में रखें: किसी भी ORM जोड़े का उपयोग करके आप अपने डेटा मॉडल को कसकर पकड़ते हैं। एक डीबीए को आपके संकलित कोड को बदलने के लिए मजबूर किए बिना डेटा मॉडल में परिवर्तन करने की कोई स्वतंत्रता नहीं है। संग्रहीत प्रक्रियाओं के साथ, आप इन प्रकार के परिवर्तनों को एक हद तक छिपा सकते हैं, क्योंकि पैरामीटर सूची और परिणाम सेट (प्रक्रिया) एक प्रक्रिया से लौटे हैं, इसके अनुबंध का प्रतिनिधित्व करते हैं, और इनर को चारों ओर बदला जा सकता है, जब तक कि अनुबंध अभी भी पूरा हो गया है ।

और भी, यदि Linq का उपयोग अधिक जटिल प्रश्नों के लिए किया जाता है, तो डेटाबेस को ट्यूनिंग करना अधिक कठिन कार्य हो जाता है। जब एक संग्रहीत प्रक्रिया धीमी गति से चल रही है, तो डीबीए पूरी तरह से अलगाव में कोड पर ध्यान केंद्रित कर सकता है, और इसमें बहुत सारे विकल्प हैं, बस इतना है कि अनुबंध अभी भी संतुष्ट है जब वह / वह किया जाता है।

मैंने कई, कई मामलों को देखा है जहां एक आवेदन में गंभीर समस्याओं को स्कीमा और कोड में संग्रहीत प्रक्रियाओं में बिना किसी परिवर्तन के संकलित, संकलित कोड में परिवर्तन द्वारा संबोधित किया गया था।

शायद एक हाइब्रिड दृष्टिकोण Linq के साथ अच्छा होगा? अलबत्ता, निश्चित रूप से संग्रहीत प्रक्रियाओं को कॉल करने के लिए उपयोग किया जा सकता है।

Comments

आपके द्वारा उपेक्षित एक विशेषता सुरक्षा है। लाइनक के साथ, आपको टेबल को सीधे आवेदन पर उजागर करना होगा। संग्रहीत प्रक्रियाओं के साथ आप उन प्रॉक्स तक पहुंच को सीमित कर सकते हैं और अपनी व्यावसायिक आवश्यकताओं को लागू कर सकते हैं।

— NotMe

"DBA को आपके संकलित कोड को बदलने के लिए मजबूर किए बिना डेटा मॉडल में परिवर्तन करने की कोई स्वतंत्रता नहीं है।" आप इसकी वकालत क्यों करेंगे? किसी को भी परिवर्तन करने के लिए "स्वतंत्रता" नहीं होनी चाहिए, यह कॉन्फ़िगरेशन प्रबंधन का बिंदु है। परिवर्तन की परवाह किए बिना तैनाती से पहले देव, परीक्षण, आदि से गुजरना चाहिए।

— नील बर्नवेल

@ नील: हाँ, लेकिन वह कोड को बदलने के लिए डेवलपर को मजबूर किए बिना विकास के माहौल में बदलाव नहीं कर सकता है।

— एडम रॉबिन्सन

मुझे यह कहने के लिए मिला है कि मैंने डेटा बेस को पूरी तरह से कसने के बारे में तर्क देखा है, और मुझे वास्तव में यकीन नहीं है कि यह मान्य है। मैं वास्तव में कभी भी ऐसी स्थिति में नहीं आया हूं (जो मामूली उदाहरणों से परे) हो जहां मैं उस डेटाबेस को बदलना चाहता हूं जिसे किसी भी तरह कोड में बदलाव की आवश्यकता नहीं है। और वास्तव में, Linq किसी भी तरह से संग्रहीत procs या पैरामीटरकृत प्रश्नों से कैसे भिन्न है। आपकी डेटा एक्सेस लेयर अभी भी अच्छी तरह से अलग और अमूर्त होनी चाहिए, चाहे आप ORM का उपयोग करें या कुछ सरल। यही वह है जो आपको ढीली युग्मन देता है, न कि आप किस तकनीक का उपयोग करते हैं। बस मेरे 2 सी

— साइमन पी स्टीवंस

मैंने एसपी के हस्ताक्षर के माध्यम से अनुप्रयोगों से परिरक्षित हर 1 स्कीमा परिवर्तन के लिए अनावश्यक रूप से लिखी गई 199 संग्रहीत प्रक्रियाओं को देखा है, लेकिन साइमन पी स्टीवंस ने जो कहा, उसी तरह एसपी के उपयोग में सिमेंटिक परिवर्तन के लिए आवश्यक परिवर्तन 100% हैं। वैसे भी समय। इस तथ्य का उल्लेख नहीं करने के लिए कि एसपी के अस्तित्व में कुछ भविष्य के देव या डीबीए हैं जो एसपी में कुछ व्यापारिक तर्क को लीक करने के लिए जाते हैं। फिर थोड़ा और, और थोड़ा और।

Answer 3

लिनक टू सकल।

Sql सर्वर क्वेरी योजनाओं को कैश करेगा, इसलिए स्पोक्स के लिए कोई प्रदर्शन लाभ नहीं है।

दूसरी ओर, आपके लाइनक बयान, तार्किक रूप से आपके आवेदन के साथ और परीक्षण किए जाएंगे। स्प्रोक्स हमेशा थोड़ा अलग होते हैं और बनाए रखने और परीक्षण करने के लिए कठिन होते हैं।

अगर मैं अभी स्क्रैच से एक नए एप्लिकेशन पर काम कर रहा था, तो मैं सिर्फ Linq का उपयोग करूंगा, कोई स्प्रोक्स नहीं।

Comments

मैं आपकी टिप्पणियों के बारे में असहमत हूं, जो कि अत्याचारों के लिए कोई लाभ नहीं है। मैंने एसक्यूएल सर्वर तक पहुँच की एक श्रंखला को एक प्रोडक्ट सिस्टम पर प्रवीण किया, और सबसे अच्छे परिणामों के बीच में तैयार + संग्रहित प्रोक्स का उपयोग किया। यहां तक ​​कि एक ही तर्क के कई कॉल में। शायद आप DB w / कम उपयोग पर सही हैं, यद्यपि।

— तिकड़ी

यदि आप हैं, और होगा, सबसे कुशल डेटाबेस क्वेरी डेवलपर, तो उस चीज़ का उपयोग करें जिसके साथ आप सबसे अधिक परिचित हैं। प्रक्रियात्मक कोड के विपरीत, आप यह नहीं कह सकते हैं "यदि यह सही उत्तर देता है, तो इसे शिप करें।"

— dkretz

@RussellH: यह .Net 3.5 का सच था, उन्होंने तय किया कि .Net 4 (L2S और L2E दोनों के लिए)

— BlueRaja - Danny Pflughoeft

@ नहीं मामला नहीं! लिनक से एसपी की तुलना में कई अधिक निष्पादन योजनाएं बनाई जाती हैं। डिबग कोड के साथ लाभ मौजूद हैं; लेकिन कंपनी की तैनाती चक्र के लिए recompiling के साथ समस्याओं; अलग-अलग कार्रवाई के सवालों का परीक्षण करने के लिए अनम्यता, जहां, आदेश द्वारा। WHERE के बयान के क्रम को बदलने से एक अलग क्वेरी संसाधित हो सकती है; पूर्व-आनयन; यह आसानी से Linq में नहीं किया जा सकता है। डेटा लेयर को ट्वीक करने के लिए उपलब्ध होना आवश्यक है। एसपी बनाए रखने और परीक्षण करने के लिए कठिन हैं? यदि आपको इसकी आदत नहीं है; लेकिन एसपी कोर और वीएलडीबी, उच्च-उपलब्धता, आदि के लिए फायदेमंद हैं! Linq छोटी परियोजनाओं, एकल काम के लिए है; इसके लिए जाओ।

— SnapJag

@SnapJag - आप सही कह रहे हैं कि sprocs आपको अधिक बढ़िया अनाज नियंत्रण देते हैं, लेकिन तथ्य यह है कि समय का 99% (यहां तक ​​कि बड़े उद्यम प्रणालियों में मैं काम करता हूं) आपको किसी भी अतिरिक्त अनुकूलन की आवश्यकता नहीं है। स्पोक्स को बनाए रखना और परीक्षण करना कठिन है कि आप उनके लिए उपयोग किए गए हैं या नहीं - मैं उनके लिए बहुत अधिक उपयोग किया जाता हूं (मैं एक डेवलपर होने से पहले एक डीबीए था) और यह सुनिश्चित करना कि प्रत्येक सीआरयूडी ऑपरेशन के लिए विभिन्न तालिकाओं के भार के लिए स्प्रो है। अप टू डेट एक दर्द है। सबसे अच्छा अभ्यास (IMHO) उस तरीके से कोड करना है जो सबसे आसान है, फिर प्रदर्शन जांच चलाएं और केवल उसी स्थान पर अनुकूलन करें जहां इसकी आवश्यकता है।

— कीथ

Answer 4

बुनियादी डेटा पुनर्प्राप्ति के लिए मैं बिना किसी हिचकिचाहट के लिनिक के लिए जा रहा हूं।

Linq में जाने के बाद से मुझे निम्नलिखित लाभ मिले हैं:

1. मेरे डीएएल को डीबग करना कभी आसान नहीं रहा।
2. जब आपका स्कीमा परिवर्तन अमूल्य हो, तो समय सुरक्षा संकलित करें।
3. तैनाती आसान है क्योंकि सब कुछ डीएलएल में संकलित है। कोई और परिनियोजन स्क्रिप्ट नहीं।
4. क्योंकि Linq IQueryable इंटरफ़ेस को लागू करने वाली किसी भी चीज़ का समर्थन कर सकता है, आप XML सिंटैक्स, ऑब्जेक्ट्स और किसी भी अन्य डेटा स्रोत को बिना किसी नए सिंटैक्स को सीखे एक ही सिंटैक्स का उपयोग कर पाएंगे।

Comments

मेरे लिए संकलन समय सुरक्षा महत्वपूर्ण है!

— bbqchickenrobot

परिनियोजन के लिए, यदि आप एक कॉरपोरेट टीम में हैं, जिसके पास एक तैनाती चक्र है और एक बग मौजूद है, जिसे जल्दी से बाहर करने की आवश्यकता है, तो QA, आदि के माध्यम से DLL की आपकी तैनाती, संभवतः एकल डेटाबेस की तैनाती के लिए पथ से अधिक सख्त है। स्क्रिप्ट। आपके फायदे एक छोटी टीम / परियोजना परिदृश्य का बेहतर प्रतिनिधित्व करते हैं।

— SnapJag

एसक्यूएल स्क्रिप्ट की तैनाती जिसे क्यूए के माध्यम से जाने की आवश्यकता नहीं है, जरूरी नहीं कि यहां अच्छी बात है।

— लियांग

Answer 5

LINQ प्रक्रिया कैश को फूला देगी

यदि कोई अनुप्रयोग LINQ to SQL का उपयोग कर रहा है और क्वेरी में स्ट्रिंग्स का उपयोग शामिल है जो लंबाई में अत्यधिक परिवर्तनशील हो सकता है, तो SQL सर्वर प्रक्रिया कैश हर संभव स्ट्रिंग लंबाई के लिए क्वेरी के एक संस्करण के साथ फूला हुआ हो जाएगा। उदाहरण के लिए, AdventureWorks2008 डेटाबेस में Person.AddressTypes तालिका के विरुद्ध बनाए गए बहुत ही सरल प्रश्नों पर विचार करें:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

यदि ये दोनों क्वेरी चल रही हैं, तो हम SQL सर्वर प्रक्रिया कैश में दो प्रविष्टियाँ देखेंगे: एक NVARCHAR (7) के साथ, और दूसरा NVARCHAR (11) के साथ। अब कल्पना कीजिए कि सैकड़ों या हजारों अलग-अलग इनपुट स्ट्रिंग्स थे, सभी अलग-अलग लंबाई के साथ। प्रक्रिया कैश अनावश्यक रूप से एक ही क्वेरी के लिए विभिन्न योजनाओं के साथ भरा जाएगा।

यहाँ और अधिक: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Comments

एक मूर्खतापूर्ण तर्क क्या है - बस एक चर का उपयोग करें और आपकी समस्या हल हो गई है।

— जॉनओपिनार

@ जॉन, यह मदद नहीं करेगा यदि आप एक शाब्दिक स्ट्रिंग के बजाय एक मान्य का उपयोग करते हैं, तो अंत में आप डेटाबेस में एक शाब्दिक स्ट्रिंग भेज रहे हैं। यह आपके कोड में एक चर की तरह लग सकता है, लेकिन यह उत्पन्न टी-एसक्यूएल में एक स्ट्रिंग होगा जो डीबी को भेजा जाता है।

— kay.one

SQLMenace: आपके द्वारा लिंक किए गए पृष्ठ के अनुसार, समस्या VS2010 में हल हो गई है।

— मार्क बायर्स

जब यह उत्तर पोस्ट किया गया था, तब यह समस्या मान्य थी, लेकिन यह तब से VS2010 में हल हो गई है, इसलिए यह अब एक मुद्दा नहीं है।

— ब्रेन

Answer 6

मुझे लगता है कि समर्थक LINQ तर्क उन लोगों से आ रहा है जिनका डेटाबेस विकास (सामान्य रूप से) के साथ इतिहास नहीं है।

खासकर अगर वीएस डीबी प्रो या टीम सूट जैसे उत्पाद का उपयोग किया जाता है, तो यहां दिए गए कई तर्क लागू नहीं होते हैं, उदाहरण के लिए:

बनाए रखने और परीक्षण करने के लिए कठिन: वी.एस. पूर्ण वाक्यविन्यास जाँच, शैली जाँच, संदर्भ और बाधा जाँच और अधिक प्रदान करता है। यह पूर्ण इकाई परीक्षण क्षमताओं और रीफैक्टरिंग उपकरण भी प्रदान करता है।

LINQ सच इकाई परीक्षण को असंभव बनाता है (मेरे दिमाग में) यह ACID परीक्षण को विफल करता है।

LINQ में डीबग करना आसान है: क्यों? VS, प्रबंधित कोड और SPs की नियमित डीबगिंग से पूर्ण चरणबद्ध अनुमति देता है।

तैनाती लिपियों के बजाय एक एकल DLL में संकलित: एक बार फिर, वीएस बचाव के लिए आता है जहां यह पूर्ण डेटाबेस का निर्माण और तैनाती कर सकता है या डेटा-सुरक्षित वृद्धिशील परिवर्तन कर सकता है।

LINQ के साथ TSQL नहीं सीखना है: नहीं, आप नहीं, लेकिन आपको LINQ सीखना है - लाभ कहाँ है?

मैं वास्तव में इसे एक लाभ के रूप में नहीं देखता हूं। अलगाव में कुछ बदलने में सक्षम होना सिद्धांत में अच्छा लग सकता है, लेकिन सिर्फ इसलिए कि एक अनुबंध को पूरा करने का मतलब यह नहीं है कि यह सही परिणाम लौटा रहा है। यह निर्धारित करने में सक्षम होने के लिए कि आपको सही परिणाम क्या हैं संदर्भ की आवश्यकता है और आपको कॉलिंग कोड से वह संदर्भ मिलता है।

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

इससे पहले कि आप सभी परेशान हों, मुझे लगता है कि LINQ का अपना स्थान है और एक भव्य भविष्य है। लेकिन जटिल, डेटा-गहन अनुप्रयोगों के लिए मुझे नहीं लगता कि यह संग्रहीत प्रक्रियाओं की जगह लेने के लिए तैयार है। यह एक दृश्य था जो मैंने इस साल टेकवीड में एक एमवीपी द्वारा गूँज रहा था (वे नाममात्र रहेंगे)।

संपादित करें: LINQ to SQL स्टोर की गई प्रक्रिया का पक्ष कुछ ऐसा है जिसे मुझे अभी भी और अधिक पढ़ने की आवश्यकता है - जो मुझे मिल रहा है उसके आधार पर मैं अपने उपरोक्त डायटरी को बदल सकता हूं;)

Comments

LINQ सीखना कोई बड़ी बात नहीं है - यह सिंटैक्टिक शुगर है। TSQL एक पूरी तरह से अलग भाषा है। सेब और संतरे।

— एडम लाससेक

LINQ सीखने का लाभ यह है कि यह एक ही तकनीक से बंधा हुआ नहीं है - क्वेरी शब्दार्थों का उपयोग XML, ऑब्जेक्ट्स इत्यादि के लिए किया जा सकता है, और यह समय के साथ विस्तारित होगा।

— डेव आर।

माना! इतने सारे लोग (डेवलपर्स) छोटी टीमों और परियोजनाओं में "स्पीड-टू-मार्केट" समाधान की तलाश कर रहे हैं। लेकिन अगर विकास कई टीमों, बड़े डेटाबेस, उच्च-मात्रा, उच्च-उपलब्धता, वितरित प्रणालियों के साथ कॉर्पोरेट शैली के अगले स्तर तक उन्नत है, तो यह LINQ का उपयोग करने के लिए एक अलग कहानी होगी! मुझे विश्वास नहीं है कि आपको बहुत समय में अपनी राय संपादित करने की आवश्यकता होगी। LINQ उन प्रोजेक्ट्स / टीमों के लिए नहीं है जो बड़ी हैं और जिनके पास कई लोग हैं, कई टीमें (Dev & DBA) हैं, और उनकी सख्त तैनाती का समय है।

— SnapJag

Answer 7

LINQ नया है और इसकी जगह है। LINQ का आविष्कार संग्रहीत प्रक्रिया को बदलने के लिए नहीं किया गया है।

यहाँ मैं कुछ प्रदर्शन मिथकों और CONS पर ध्यान केंद्रित करूँगा, "LINQ to SQL" के लिए, निश्चित रूप से मैं पूरी तरह से हो सकता हूं ;-)

(1) लोग कहते हैं कि LINQ स्टेटमेंट SQL सर्वर में "कैश" कर सकता है, इसलिए यह प्रदर्शन नहीं खोता है। आंशिक रूप से सच है। "LINQ to SQL" वास्तव में TSQ स्टेटमेंट में LINQ सिंटैक्स का अनुवाद करने वाला रनटाइम है। इसलिए प्रदर्शन के दृष्टिकोण से, हार्ड कोडित ADO.NET SQL स्टेटमेंट का LINQ से कोई अंतर नहीं है।

(2) एक उदाहरण को देखते हुए, एक ग्राहक सेवा यूआई में एक "खाता स्थानांतरण" फ़ंक्शन है। यह फ़ंक्शन स्वयं 10 DB तालिकाओं को अपडेट कर सकता है और एक शॉट में कुछ संदेश लौटा सकता है। LINQ के साथ, आपको स्टेटमेंट्स का एक सेट बनाना होगा और उन्हें SQL सर्वर पर एक बैच के रूप में भेजना होगा। इस अनुवादित LINQ-> TSQL बैच का प्रदर्शन शायद ही संग्रहीत कार्यविधि से मेल खा सकता है। कारण? क्योंकि आप अंतर्निहित SQL प्रोफाइलर और निष्पादन योजना टूल का उपयोग करके संग्रहीत प्रक्रिया में कथन की सबसे छोटी इकाई को ट्वीक कर सकते हैं, आप LINQ में ऐसा नहीं कर सकते।

बिंदु यह है, जब एकल DB तालिका और डेटा CRUD के छोटे सेट पर बात की जाती है, तो LINQ SP जितना तेज़ है। लेकिन बहुत अधिक जटिल तर्क के लिए, संग्रहीत कार्यविधि अधिक प्रदर्शन करने योग्य है।

(3) "LINQ to SQL" प्रदर्शन हॉग को पेश करने के लिए आसानी से newbies बनाता है। कोई भी वरिष्ठ TSQL व्यक्ति आपको बता सकता है कि CURSOR का उपयोग न करें (मूल रूप से आपको ज्यादातर मामलों में TSQL में CURSOR का उपयोग नहीं करना चाहिए)। LINQ और क्वेरी के साथ आकर्षक "foreach" लूप के साथ, यह नौसिखिया के लिए इस तरह के कोड को लिखना इतना आसान है:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

आप देख सकते हैं कि यह आसान सभ्य कोड बहुत आकर्षक है। लेकिन हुड के तहत, .NET रनटाइम बस इसे अपडेट बैच में अनुवाद करता है। यदि केवल 500 लाइनें हैं, तो यह 500 पंक्ति TSQL बैच है; अगर मिलियन लाइनें हैं, तो यह एक हिट है। बेशक, अनुभवी उपयोगकर्ता इस काम को करने के लिए इस तरह का उपयोग नहीं करेंगे, लेकिन बात यह है, इस तरह से गिरना इतना आसान है।

Comments

C / C ++ / C # में संकेत के साथ विफल होना आसान है, क्या इसका मतलब यह है कि इसका उपयोग कभी नहीं किया जाना चाहिए?

— bbqchickenrobot

कितने मध्य स्तर के प्रोग्रामर पॉइंटर्स से निपटते हैं? Linq इस क्षमता को किसी भी स्तर के कोडर से उजागर करता है जिसका अर्थ है कि त्रुटि का जोखिम नाटकीय रूप से बढ़ जाता है।

— जैक्स

आप वरिष्ठ TSQL आदमी के साथ LINQ में newbies की तुलना कर रहे हैं। वास्तव में उचित तुलना नहीं। मैं आपके कोड से सहमत हूं, LINQ सामान्य रूप से बैच अपडेट / डिलीट के लिए परफॉर्मर नहीं है। हालांकि, मैं LINQ और SP के बीच अधिकांश प्रदर्शन तर्क देता हूं, दावे हैं, लेकिन माप पर आधारित नहीं है

— liang

Answer 8

सबसे अच्छा कोड कोई कोड नहीं है, और संग्रहीत प्रक्रियाओं के साथ आपको डेटाबेस में कम से कम कुछ कोड लिखना होगा और इसे कॉल करने के लिए एप्लिकेशन में कोड, जबकि LINQ से SQL या LINQ से एंटिटीज़ तक, आपको कोई अतिरिक्त लिखना नहीं है किसी भी अन्य LINQ क्वेरी से परे कोड एक संदर्भ वस्तु को तत्काल करने से अलग है।

Answer 9

LINQ निश्चित रूप से अनुप्रयोग-विशिष्ट डेटाबेस और छोटे व्यवसायों में अपना स्थान रखता है।

लेकिन एक बड़े उद्यम में, जहां केंद्रीय डेटाबेस कई अनुप्रयोगों के लिए आम डेटा के केंद्र के रूप में काम करते हैं, हमें अमूर्तता की आवश्यकता होती है। हमें सुरक्षा को केंद्र में रखने और पहुँच इतिहास दिखाने की आवश्यकता है। हमें प्रभाव विश्लेषण करने में सक्षम होने की आवश्यकता है: यदि मैं एक नई व्यावसायिक आवश्यकता की पूर्ति के लिए डेटा मॉडल में एक छोटा सा बदलाव करता हूं, तो किन प्रश्नों को बदलने की आवश्यकता है और किन अनुप्रयोगों को फिर से जांचने की आवश्यकता है? दृश्य और संग्रहीत प्रक्रियाएं मुझे वह देती हैं। अगर LINQ वह सब कर सकता है, और हमारे प्रोग्रामरों को अधिक उत्पादक बना सकता है, तो मैं इसका स्वागत करता हूँ - क्या किसी को इस तरह के वातावरण में इसका उपयोग करने का अनुभव है?

Comments

आपने अच्छा मुद्दा उठाया; इस मामले में LINQ एक विकल्प नहीं है।

— मेटा-नाइट

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

— bbqchickenrobot

Answer 10

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

मैं वास्तव में इसे एक लाभ के रूप में नहीं देखता हूं। अलगाव में कुछ बदलने में सक्षम होना सिद्धांत में अच्छा लग सकता है, लेकिन सिर्फ इसलिए कि एक अनुबंध को पूरा करने का मतलब यह नहीं है कि यह सही परिणाम लौटा रहा है। यह निर्धारित करने में सक्षम होने के लिए कि आपको सही परिणाम क्या हैं संदर्भ की आवश्यकता है और आपको कॉलिंग कोड से वह संदर्भ मिलता है।

Answer 11

IMHO, RAD = LINQ, RUP = संग्रहित गुण। मैंने कई वर्षों तक एक बड़ी फॉर्च्यून 500 कंपनी के लिए काम किया, प्रबंधन सहित कई स्तरों पर, और स्पष्ट रूप से, मैं आरएडी डेवलपर्स को आरएडी विकास करने के लिए कभी भी काम पर नहीं रखूंगा। वे इतने चुप हैं कि उन्हें इस प्रक्रिया के अन्य स्तरों पर क्या करना है इसका बहुत सीमित ज्ञान है। एक शांत वातावरण के साथ, यह बहुत विशिष्ट प्रवेश बिंदुओं के माध्यम से डेटा पर DBAs नियंत्रण देने के लिए समझ में आता है, क्योंकि अन्य लोग स्पष्ट रूप से डेटा प्रबंधन को पूरा करने के सर्वोत्तम तरीकों को नहीं जानते हैं।

लेकिन बड़े उद्यम विकास के क्षेत्र में बहुत धीमी गति से आगे बढ़ते हैं , और यह बेहद महंगा है। ऐसे समय होते हैं जब आपको समय और धन दोनों को बचाने के लिए तेजी से आगे बढ़ने की आवश्यकता होती है, और LINQ हुकुम में और अधिक प्रदान करता है।

कभी-कभी मुझे लगता है कि डीबीए लिनक्यू के खिलाफ पक्षपाती हैं क्योंकि उन्हें लगता है कि इससे उनकी नौकरी की सुरक्षा को खतरा है। लेकिन यह जानवर, देवियों और सज्जनों की प्रकृति है।

Comments

हाँ, हमें DBA के लिए पूरे दिन इंतजार करना पड़ता है ताकि आप एक Stored Proc को उत्पादन में धकेलने का अनुरोध कर सकें। ऐसा न करने से हमारा दिल टूट जाएगा!

— सैम

Answer 12

मुझे लगता है कि आपको कुछ भी वास्तविक होने के लिए प्रोक्स के साथ जाने की आवश्यकता है।

ए) अपने सभी तर्क को लिंकन में लिखने का मतलब है कि आपका डेटाबेस कम उपयोगी है क्योंकि केवल आपका आवेदन ही इसका उपभोग कर सकता है।

बी) मुझे यकीन नहीं है कि वस्तु मॉडलिंग वैसे भी रिलेशनल मॉडलिंग से बेहतर है।

ग) एसक्यूएल में संग्रहीत प्रक्रिया का परीक्षण और विकास किसी भी दृश्य स्टूडियो वातावरण में संकलित संपादन चक्र की तुलना में बहुत तेजी से नरक है। आप बस F5 को संपादित करते हैं, और हिट का चयन करते हैं और आप दौड़ से बाहर हैं।

डी) असेंबली की तुलना में संग्रहीत प्रक्रियाओं को प्रबंधित करना और तैनात करना आसान है .. आप बस फ़ाइल को सर्वर पर रखें, और F5 दबाएं ...

ई) Linq to sql अभी भी कई बार भद्दा कोड लिखती है जब आप इसकी उम्मीद नहीं करते हैं।

ईमानदारी से, मुझे लगता है कि अंतिम बात टी-एसक्यूएल को बढ़ाने के लिए एमएस के लिए होगी ताकि यह एक तरह से एक प्रक्षेपण प्रक्षेपण कर सके जिस तरह से लिनिक करता है। t-sql को पता होना चाहिए कि क्या आप ऑर्डर करना चाहते हैं। उदाहरण के लिए।

Answer 13

LINQ संग्रहीत प्रक्रियाओं के उपयोग को प्रतिबंधित नहीं करता है। मैंने LINQ-SQL और LINQ-storeproc के साथ मिश्रित मोड का उपयोग किया है । व्यक्तिगत रूप से, मुझे खुशी है कि मुझे संग्रहित procs .... pwet-tu लिखना नहीं आता।

Answer 14

इसके अलावा, संभावित 2.0 रोलबैक का मुद्दा है। मेरा विश्वास करो यह मेरे साथ दो बार हुआ है इसलिए मुझे यकीन है कि यह दूसरों के साथ हुआ है।

मैं यह भी मानता हूं कि अमूर्तता सबसे अच्छी है। इस तथ्य के साथ, ORM का मूल उद्देश्य RDBMS को OO अवधारणाओं से अच्छी तरह मेल करना है। हालांकि, अगर OO अवधारणाओं से थोड़ा विचलित करने के लिए LINQ से पहले सब कुछ ठीक काम करता है, तो उन्हें स्क्रू करें। अवधारणाओं और वास्तविकता हमेशा एक साथ अच्छी तरह से फिट नहीं होते हैं। आईटी में आतंकवादी जोनल के लिए कोई जगह नहीं है।

Answer 15

मैं मान रहा हूँ आप Linq To Sql मतलब है

किसी भी CRUD कमांड के लिए किसी भी तकनीक बनाम स्टोर की गई प्रक्रिया के प्रदर्शन को प्रोफाइल करना आसान है। इस मामले में दोनों के बीच कोई भी अंतर नगण्य होगा। एक वास्तविक अंतर होने पर यह पता लगाने के लिए 100,000 से अधिक 5 (सरल प्रकार) फ़ील्ड ऑब्जेक्ट के लिए प्रोफाइलिंग का प्रयास करें।

दूसरी ओर वास्तविक डील-ब्रेकर इस सवाल पर होगा कि क्या आप अपने डेटाबेस पर अपने व्यापार तर्क को रखने में सहज महसूस करते हैं या नहीं, जो संग्रहीत प्रक्रियाओं के खिलाफ एक तर्क है।

Comments

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

— HLGEM

व्यावसायिक तर्क डेटाबेस में नहीं जाना चाहिए। यह एक प्रोग्रामिंग भाषा में होना चाहिए जहां यह आसानी से डीबग और प्रबंधित हो। यह तब वस्तुओं के रूप में अनुप्रयोगों में साझा किया जा सकता है। कुछ नियम डेटाबेस में हो सकते हैं लेकिन व्यावसायिक तर्क नहीं।

— स्पेस

Answer 16

गुरुओं के अनुसार, मैं LINQ को मोटरसाइकिल और SP को कार के रूप में परिभाषित करता हूं। यदि आप एक छोटी यात्रा के लिए जाना चाहते हैं और केवल छोटे यात्री हैं (इस मामले में 2), तो LINQ के साथ शान से जाएं। लेकिन अगर आप एक यात्रा के लिए जाना चाहते हैं और बड़े बैंड हैं, तो मुझे लगता है कि आपको एसपी चुनना चाहिए।

निष्कर्ष के रूप में, मोटरसाइकिल या कार के बीच चयन आपके मार्ग (व्यवसाय), लंबाई (समय), और यात्रियों (डेटा) पर निर्भर करता है।

आशा है कि यह मदद करता है, मैं गलत हो सकता है। : डी

Comments

दोस्तों की मोटर साइकिल की सवारी से मृत्यु हो गई है: P

— एलेक्स

कार चलाने के साथ ही लोगों की मौत हो गई।

— लियांग

हाँ आप गलत हैं।

— असद अली

Answer 17

LINQ की ओर झुकाव वाले ये सभी उत्तर मुख्य रूप से EASE DEVELOPMENT के बारे में बात कर रहे हैं जो कमोबेश कोडिंग या आलस्य की खराब गुणवत्ता से जुड़े हैं। मैं ही ऐसा हूं।

कुछ फायदे या लाइनक, मैं यहाँ पढ़ता हूँ, परीक्षण करना आसान, डीबग करना आसान आदि, लेकिन ये वे नहीं हैं जहाँ अंतिम आउटपुट या अंतिम उपयोगकर्ता से जुड़े हैं। यह हमेशा प्रदर्शन पर अंतिम उपयोगकर्ता के लिए परेशानी का कारण बन रहा है। Whats मेमोरी में कई चीजों को लोड कर रहा है और फिर LINQ का उपयोग करने पर फ़िल्टर लागू कर रहा है?

फिर से टाइपसिटी, सावधानी बरतें कि "हम गलत टाइपकास्टिंग से बचने के लिए सावधान हैं" जो फिर से खराब गुणवत्ता की है जिसे हम linq का उपयोग करके सुधारने की कोशिश कर रहे हैं। उस स्थिति में भी, यदि डेटाबेस में कुछ भी परिवर्तन होता है, उदाहरण के लिए स्ट्रिंग कॉलम का आकार, तो linq को फिर से संकलित करने की आवश्यकता है और इसके बिना टाइपसेफ़ नहीं होगा .. मैंने कोशिश की।

हालांकि, हमने पाया है कि LINQ के साथ काम करते समय अच्छा, मीठा, दिलचस्प आदि है, इससे डेवलपर को आलसी बनाने का नुकसान होता है :) और यह साबित हो जाता है कि यह स्टोरेड प्रोक्स की तुलना में प्रदर्शन पर 1000 गुना खराब (सबसे खराब) हो सकता है।

आलसी होना बंद करो। मैं पूरी कोशिश कर रहा हूं। :)

Comments

स्मृति में सब कुछ लोड हो रहा है और इसे फ़िल्टर करें? Linq क्वेरी को डेटाबेस के हिस्से के रूप में फ़िल्टर भेज सकता है, और फ़िल्टर किए गए परिणाम सेट लौटाता है।

— लियांग

ऐसे बहुत से लोग हैं जो मानते हैं कि LINQ सभी डेटा को लोड करता है और फ़ॉरच लूप का उपयोग करके इसे संसाधित करता है। यह गलत है। यह बस एक sql क्वेरी में संकलित हो जाता है और CRUD के अधिकांश कार्यों के लिए लगभग समान प्रदर्शन प्रदान करता है। लेकिन हां यह सिल्वर बुलेट नहीं है। ऐसे मामले हैं जहां टी-एसक्यूएल या संग्रहीत प्रोक्स का उपयोग करना बेहतर हो सकता है।

— यह

मैं दोनों के तर्क-वितर्क से सहमत हूं। हालाँकि, यह पूरी तरह से सच नहीं है कि linq DBMS को इस पर काम करने के लिए सभी फ़िल्टर भेजता है। कुछ चीजें हैं जो स्मृति में काम करती हैं उनमें से एक अलग है।

— मनीष

Answer 18

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

Answer 19

संग्रहीत प्रक्रिया परीक्षण को आसान बनाती है और आप एप्लिकेशन कोड को स्पर्श किए बिना क्वेरी को बदल सकते हैं। Linq के साथ, एक डेटा प्राप्त करने का मतलब यह नहीं है कि सही डेटा। और डेटा की शुद्धता का परीक्षण करने का अर्थ है आवेदन चलाना लेकिन संग्रहीत कार्यविधि के साथ अनुप्रयोग को स्पर्श किए बिना परीक्षण करना आसान है।

Answer 20

परिणाम के रूप में संक्षेप किया जा सकता है

छोटे साइटों और प्रोटोटाइप के लिए LinqToSql। यह वास्तव में प्रोटोटाइप के लिए समय बचाता है।

Sps: यूनिवर्सल। मैं अपनी जिज्ञासाओं को ठीक कर सकता हूं और हमेशा एक्चुअल एक्ज़ीक्यूशनप्लान / एस्टिमेटेड एक्ज़ीक्यूशनप्लान की जांच कर सकता हूं।

Answer 21

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

Comments

इसका क्या मतलब है?

— तेमन शिपाही

Answer 22

LINQ और SQL दोनों के अपने स्थान हैं। दोनों के अपने नुकसान और फायदे हैं।

कभी-कभी जटिल डेटा पुनर्प्राप्ति के लिए आपको संग्रहीत प्रॉक्सेस की आवश्यकता हो सकती है। और कभी-कभी आप चाहते हैं कि अन्य लोग Sql Server Management Studio में आपके संग्रहित खरीद का उपयोग कर सकें।

तेजी से CRUD विकास के लिए Linq to Entities महान है।

सुनिश्चित करें कि आप केवल एक या दूसरे का उपयोग करके एक ऐप बना सकते हैं। या आप इसे मिला सकते हैं। यह सब आपकी आवश्यकताओं के लिए आता है। लेकिन एसक्यूएल संग्रहीत procs जल्द ही किसी भी समय दूर नहीं जाएगा।