संग्रहीत कार्यविधियों के साथ SQL VS ADO.NET में इकाई फ्रेमवर्क VS LINQ? [बन्द है]

Question

आप उनमें से प्रत्येक को किस तरह से रेट करेंगे:

1. प्रदर्शन
2. विकास की गति
3. नीट, सहज, बनाए रखने योग्य कोड
4. लचीलापन
5. संपूर्ण

मुझे अपनी एसक्यूएल पसंद है और इसलिए हमेशा ADO.NET और संग्रहीत कार्यविधियों का एक डाई-हार्ड प्रशंसक रहा हूं, लेकिन मैंने हाल ही में Linq के साथ एसक्यूएल के साथ एक नाटक किया था और इसे उड़ा दिया गया था कि मैं कितनी जल्दी अपनी डेटाएयर परत को लिख रहा था और खर्च करने का फैसला किया है कुछ समय वास्तव में या तो SQL या EF को Linq समझ ... या न ही?

मैं सिर्फ यह जांचना चाहता हूं कि इनमें से किसी भी तकनीक में कोई बड़ी खामी नहीं है जो मेरे शोध के समय को बेकार कर दे। ईजी का प्रदर्शन बहुत ही भयानक है, यह साधारण ऐप्स के लिए अच्छा है लेकिन केवल आपको इतना दूर ले जा सकता है।

अद्यतन: क्या आप ORM VS SPs के बजाय EF VS L2S VS SP पर ध्यान केंद्रित कर सकते हैं। मुझे मुख्य रूप से EF VS L2S में दिलचस्पी है। लेकिन मैं उन्हें संग्रहीत गद्य की तुलना में बहुत उत्सुक हूँ क्योंकि सादे SQl कुछ ऐसा है जिसके बारे में मुझे बहुत कुछ पता है।

Comments

रचनात्मक नहीं है और अभी तक इतने सारे उत्थान? ...;)

— ब्रिटिशड्यूप्लर

मैं नहीं देखता कि किसी ने इसे रचनात्मक क्यों नहीं माना। यह मुझे बहुत अच्छा लगता है। मुझ से +1।

— तनुष्का

मेरे विचार में यह एक उत्कृष्ट प्रश्न है। व्यक्तिगत रूप से, मैंने एंटिटी फ्रेमवर्क और सभी समान ओआरएम को देखा है जो सादे / सरल ADO.Net कोड की तुलना में धीमी है। मैंने यह परीक्षण 2 साल पहले और फिर एक हफ्ते पहले किया था। मैं इस बारे में निश्चित नहीं हूं कि LINQ से SQL EF से तुलना कैसे करते हैं। लेकिन ADO.Net प्रदर्शन में हमेशा सर्वश्रेष्ठ रहेगी। यदि आप देव समय को बचाना चाहते हैं, तो एंटिटी फ्रेमवर्क एक अच्छा उपकरण है, लेकिन निश्चित रूप से नहीं जब प्रदर्शन आपकी प्राथमिक चिंता है।

— सुनील

@ समयरेखा: डेटाबेस तंत्र पर भरोसा नहीं करने की प्रवृत्ति है। प्रत्येक डेटाबेस इंजन की अपनी संग्रहीत कार्यविधि भाषा होती है, इसलिए अतिरिक्त अधिगम होता है। 99.9% डेवलपर्स ORM पर भरोसा कर सकते हैं, जो काफी अच्छा कोड बनाता है और स्वचालित रूप से SQL बनाता है। साधारण CRUD के मामले में प्रदर्शन अंतर मामूली है। संग्रहीत प्रक्रियाएं विकसित और बनाए रखने के लिए कठिन हैं। कुछ साल पहले, जब कोई ओआरएम नहीं थे और कुछ भी जादुई और स्वचालित रूप से डेटाबेस से उत्पन्न नहीं हुआ था। लेखन SPs को इतना समय लेने वाला नहीं माना जाता था, क्योंकि यह अनुप्रयोग में SQL कथन लिखने के लिए वैकल्पिक था।

— लुक्लेड

@ सुनील सही है, हालांकि पर्याप्त नहीं है। मुद्दा यह है कि हर कोई सोचता है कि उनकी प्राथमिक चिंता ऐप का प्रदर्शन है। जब मैं उन ऐप्स के बारे में बात करता हूं, जिन्हें शीर्ष प्रदर्शन की आवश्यकता होती है, तो मुझे लगता है कि कट्टर सी ++ MMOs या उच्च-मात्रा वाले ग्राहक-सामना करने वाले डेटाबेस लेनदेन उच्च लाखों में हैं। आपको वास्तव में ऑब्जेक्ट-ओरिएंटेड सिद्धांतों जैसे रखरखाव , पठनीयता , दृढ़ता अज्ञानता और डोमेन लॉजिक पृथक्करण पर ध्यान देना चाहिए । खासकर जब कई मामलों में प्रदर्शन में वृद्धि मामूली-से-सबसे अच्छी या गैर-मौजूद होती है।

— सुमेरे

Answer 1

सबसे पहले, यदि आप एक नया प्रोजेक्ट शुरू कर रहे हैं, तो Entity Framework ("EF") के साथ जाएं - यह अब बहुत बेहतर SQL उत्पन्न करता है (Linq to SQL do जैसा) और इसे बनाए रखना आसान है और Linq से SQL की तुलना में अधिक शक्तिशाली है (" L2S ")। .NET 4.0 की रिलीज के अनुसार, मैं Linq को SQL की एक अप्रचलित तकनीक मानता हूं। एमएस L2S विकास को आगे नहीं बढ़ाने के बारे में बहुत खुला है।

1) प्रदर्शन

यह जवाब देने के लिए मुश्किल है। अधिकांश एकल-इकाई संचालन ( CRUD ) के लिए आपको सभी तीन तकनीकों के साथ समान प्रदर्शन के बारे में पता चलेगा। आपको यह जानना होगा कि EF और Linq SQL को उनके पूर्ण रूप से उपयोग करने के लिए कैसे काम करते हैं। मतदान संबंधी प्रश्नों जैसे उच्च-मात्रा संचालन के लिए, आप अपनी इकाई क्वेरी EF / L2S को "संकलित" करना चाह सकते हैं, ताकि रूपरेखा को लगातार SQL को पुनर्जीवित न करना पड़े, या आप स्केलेबिलिटी समस्याओं में भाग सकें। (संपादन देखें)

बल्क अपडेट के लिए जहां आप भारी मात्रा में डेटा अपडेट कर रहे हैं, कच्ची SQL या एक संग्रहीत प्रक्रिया हमेशा ORM समाधान से बेहतर प्रदर्शन करेगी क्योंकि आपको अपडेट करने के लिए ORM के तार पर डेटा को मार्शल नहीं करना पड़ता है।

2) विकास की गति

ज्यादातर परिदृश्यों में, EF विकास की गति की बात आने पर नग्न SQL / संग्रहित प्रोक्स को उड़ा देगा। EF डिज़ाइनर आपके डेटाबेस से आपके मॉडल को अपडेट कर सकता है क्योंकि यह (अनुरोध पर) बदलता है, इसलिए आप अपने ऑब्जेक्ट कोड और अपने डेटाबेस कोड के बीच सिंक्रनाइज़ेशन समस्याओं में नहीं चलते हैं। केवल उसी समय जब मैं ORM का उपयोग करने पर विचार नहीं करूंगा, जब आप रिपोर्टिंग / डैशबोर्ड प्रकार का अनुप्रयोग कर रहे हों, जहाँ आप कोई अद्यतन नहीं कर रहे हों, या जब आप डेटाबेस पर कच्चे डेटा रखरखाव कार्य करने के लिए केवल एक अनुप्रयोग बना रहे हों।

3) नीट / मेंटेनेंस कोड

हाथ नीचे, EF SQL / sprocs धड़कता है। क्योंकि आपके रिश्ते मॉडलिंग कर रहे हैं, आपके कोड में शामिल होने के कारण अपेक्षाकृत कम हैं। अधिकांश प्रश्नों के लिए संस्थाओं के रिश्ते पाठक के लिए लगभग स्व-स्पष्ट हैं। वास्तव में आपके डेटा का क्या हो रहा है, यह समझने के लिए टियर से टीयर डीबगिंग या मल्टीपल SQL / मिडिल टियर के माध्यम से जाने से कुछ नहीं होता है। ईएफ आपके डेटा मॉडल को आपके कोड में बहुत शक्तिशाली तरीके से लाता है।

4) लचीलापन

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

5) कुल मिलाकर

संग्रहीत प्रक्रियाओं का उपयोग करके ORM बनाम चुनने का झूठा द्वंद्ववाद में मत फंसो। आप एक ही अनुप्रयोग में दोनों का उपयोग कर सकते हैं, और आपको शायद करना चाहिए। बड़े थोक संचालन को संग्रहीत प्रक्रियाओं या एसक्यूएल (जिसे वास्तव में ईएफ द्वारा कहा जा सकता है) में जाना चाहिए, और ईएफ का उपयोग आपके सीआरयूडी संचालन और आपकी अधिकांश मध्य-स्तरीय आवश्यकताओं के लिए किया जाना चाहिए। शायद आप अपनी रिपोर्ट लिखने के लिए SQL का उपयोग करना चाहते हैं। मुझे लगता है कि कहानी का नैतिक रूप वैसा ही है जैसा वह हमेशा से रहा है। इस काम के लिए सही उपकरण का उपयोग करें। लेकिन यह पतला है, EF आजकल बहुत अच्छा है (.NET 4.0 के रूप में)। कुछ वास्तविक समय पढ़ने और इसे गहराई से समझने में बिताएं और आप आसानी से कुछ अद्भुत, उच्च प्रदर्शन वाले एप्लिकेशन बना सकते हैं।

संपादित करें : EF 5 ऑटो-संकलित LINQ क्वेरी के साथ इस हिस्से को थोड़ा सरल करता है , लेकिन वास्तविक उच्च मात्रा वाले सामान के लिए, आपको निश्चित रूप से परीक्षण और विश्लेषण करना होगा कि वास्तविक दुनिया में आपके लिए सबसे अच्छा क्या है।

Comments

एकदम शानदार जवाब। मैं अब तेजी से एक ऐप विकसित करने के लिए ईएफ का उपयोग कर रहा हूं। यदि प्रदर्शन एक समस्या बन जाता है, तो स्टोर किए गए प्रोक्स को बुरी तरह से प्रदर्शन करने वाले ईएफ प्रश्नों को सुधारने के लिए लाया जाएगा। धन्यवाद!

— ब्रिटिशड्यूलर

@BishishDeveloper: इसके अलावा, विचारों का उपयोग करने की शक्ति भी मत भूलना। हमने अपनी L2S परियोजनाओं में कुछ दृश्यों को परिभाषित करने और उन्हें ढाँढ़स देने में बहुत सफलता हासिल की है जहाँ फ्रेमवर्क खराब प्रश्नों को लिखने के लिए प्रतीत हो रहा है। इस तरह, हम अपने एसक्यूएल लिखने के सभी लाभों के साथ फ्रेमवर्क का उपयोग करने के सभी लाभ प्राप्त करते हैं।

— डेव मार्कल

मैं भी दृश्यों का उपयोग कर रहा हूं;) ईएफ के गैर-क्रॉस डीबी सीमा के लिए एक काम के रूप में अधिक। हालांकि अनुकूलन के लिए उपयोग के लिए अच्छा विचार है। धन्यवाद

— BritishDeveloper

निश्चित रूप से एक शानदार प्रतिक्रिया। बस मैं L2S बनाम EF4 के साथ अपने अनुभव में एक अवलोकन जोड़ना चाहता था। L2S -> EF4 से अदला-बदली के बाद हमें एहसास हुआ कि हम कई अलग-अलग RDMBS का उपयोग कर सकते हैं ... लेकिन, MSSQL चलाने के दौरान अभी भी प्रदर्शन ड्रॉप मुख्य रूप से मेरे ऐप के GUI क्षेत्र में दिखाया गया है। L2S में परिणाम के लिए डेटाबाइंडिंग EF4 की तुलना में बहुत तेज थी। यह बिल्कुल उसी डीबी पर एक ही क्वेरी है। यहां एक बात ध्यान देने वाली है कि मैं 90k + रिकॉर्ड वापस कर रहा हूं इसलिए अंतर बहुत स्पष्ट था। शायद छोटे सेट पर यह कोई समस्या नहीं है? यकीन नहीं है कि यह उच्च वॉल्यूम साइटों के साथ कैसे पैमाने पर होगा ...

— bbqchickenrobot

अच्छी प्रतिक्रिया। मैंने अभी LINQ-to-Entities के साथ काम करते हुए 4 सप्ताह बिताए हैं, इसमें सब कुछ शामिल करने की कोशिश की जा रही है, अंत में यह महसूस करने से पहले कि आपको बल्क कॉपी, बल्क डिलीट, किसी डेटाबेस से डुप्लिकेट के अल्ट्रा तेजी से हटाने आदि जैसी चीजों के लिए देशी एसक्यूएल की जरूरत है। नौकरी के लिए सही उपकरण, LINQ से Entities के ढांचे के साथ देशी SQL को मसलने में कोई शर्म नहीं है।

— कंटैंगो

Answer 2

संग्रहित प्रक्रियाएं:

(+)

• महान लचीलापन
• SQL पर पूर्ण नियंत्रण
• उच्चतम प्रदर्शन उपलब्ध है

(-)

• SQL का ज्ञान आवश्यक है
• संग्रहीत प्रक्रिया स्रोत नियंत्रण से बाहर हैं
• समान तालिका और फ़ील्ड नामों को निर्दिष्ट करते हुए "खुद को दोहराते हुए" की पर्याप्त मात्रा। DB इकाई का नाम बदलने और इसके लिए कुछ संदर्भों को गायब करने के बाद एप्लिकेशन को तोड़ने का उच्च मौका।
• विकास धीमा

ORM:

(+)

• त्वरित विकास
• स्रोत नियंत्रण के तहत अब डेटा एक्सेस कोड
• आप DB में परिवर्तन से अलग-थलग हैं। यदि ऐसा होता है तो आपको केवल एक जगह अपने मॉडल / मैपिंग को अपडेट करना होगा।

(-)

• प्रदर्शन और खराब हो सकता है
• SQL ORM पर कोई या कम नियंत्रण उत्पन्न नहीं करता है (अक्षम या बदतर छोटी गाड़ी हो सकता है)। हस्तक्षेप करने और इसे कस्टम संग्रहित प्रक्रियाओं के साथ बदलने की आवश्यकता हो सकती है। यह आपके कोड को गन्दा करेगा (कोड में कुछ LINQ, कोड में कुछ SQL और / या स्रोत नियंत्रण से बाहर DB में)।
• जैसा कि कोई भी अमूर्तता "उच्च-स्तरीय" डेवलपर्स का उत्पादन कर सकती है, जिसे यह पता नहीं है कि यह हुड के नीचे कैसे काम करता है

---

सामान्य ट्रेडऑफ एक महान लचीलेपन के बीच होता है और आप जो कर सकते हैं उसमें बहुत समय गंवाने और प्रतिबंधित होने के बीच होता है, लेकिन यह बहुत जल्दी हो जाता है।

इस सवाल का कोई सामान्य जवाब नहीं है। यह पवित्र युद्धों की बात है। इसके अलावा हाथ और अपनी आवश्यकताओं पर एक परियोजना पर निर्भर करता है। क्या आप के लिए सबसे अच्छा काम करता है उठाओ।

Comments

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

— ली गुन

+1 के लिएAs any abstraction can produce "high-level" developers having no idea how it works under the hood

— नवफाल

सहमत, स्रोत नियंत्रण तर्क गलत है। हम हमेशा अपने डेटाबेस निर्माण स्क्रिप्ट को svn में संग्रहीत करते हैं। डेटाबेस एप्लिकेशन विकसित करते समय आप डेटाबेस को स्रोत नियंत्रण से बाहर कैसे रख सकते हैं?

— Wout

ईएफ उच्च उपलब्धता और उच्च प्रदर्शन के लिए वास्तव में उपयुक्त नहीं है, मैं डीबीए आदमी नहीं हूं, लेकिन मैं यह नहीं देखता कि ईएफ क्या प्रदान करता है जो कोड को आसान बनाता है।

— जॅमी

इसलिए, हम लचीलेपन, पूर्ण नियंत्रण और "तीव्र विकास" के लिए प्रदर्शन छोड़ रहे हैं और कोड परिवर्तन से बचते हैं यदि DB बदलता है। मेरे लिए शुद्ध आलस्य की तरह लगता है।

— user2966445

Answer 3

आपका प्रश्न मूल रूप से ओ / आरएम बनाम हैंड राइटिंग एसक्यूएल है

एक ORM या सादे SQL का उपयोग?

कुछ अन्य O / RM समाधानों पर नज़र डालें, L2S केवल एक ही नहीं है (NHibernate, ActiveCecre)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

विशिष्ट प्रश्नों को संबोधित करने के लिए:

1. O / RM समाधान की गुणवत्ता पर निर्भर करता है, L2S SQL उत्पन्न करने में बहुत अच्छा है
2. जब आप प्रक्रिया को पूरा कर लेते हैं तो ओ / आरएम का उपयोग करते हुए यह सामान्य रूप से बहुत तेज़ होता है
3. कोड भी आमतौर पर बहुत अधिक खाने योग्य और अधिक बनाए रखने योग्य होता है
4. सीधे एसक्यूएल की इच्छा आपको अधिक लचीलापन देगी, लेकिन अधिकांश ओ / आरएम सभी जटिल प्रश्नों को कर सकते हैं
5. कुल मिलाकर मैं एक O / RM के साथ जाने का सुझाव दूंगा, लचीलेपन की कमी लापरवाही है

Comments

@ डेविड धन्यवाद, लेकिन यह ORM बनाम SQL नहीं है। मैं ORM को स्थानांतरित करने के लिए देख रहा हूँ और सीखने में समय निवेश करने के लिए जो सोच रहा हूँ: एफई या L2S (जब तक कि वे संग्रहित Procs की तुलना में बकवास कर रहे हैं)

— BritishDeveloper

मैं निश्चित रूप से कहूंगा कि वे संग्रहीत procs की तुलना में बकवास नहीं हैं, और एक साइड लाभ यह है कि आपके पास डेटाबेस में कोड स्प्रेड नहीं है। व्यक्तिगत रूप से मुझे L2S पसंद है, लेकिन मैंने इस बिंदु पर EF के साथ बहुत कुछ नहीं किया है, और ऐसा प्रतीत होता है कि L2EF इसे दबाने जा रहा है, इसलिए मैं EF जाऊंगा। इसके अलावा, एक बार जब आप लिनक जाते हैं, तो आप वापस नहीं जाते हैं।

— BlackICE

Answer 4

LINQ-to-SQL एक उल्लेखनीय तकनीक है जो उपयोग करने के लिए बहुत सरल है, और बड़े द्वारा पीछे के अंत तक बहुत अच्छे प्रश्नों को उत्पन्न करता है। LINQ-to-EF को इसे दबाने के लिए स्लेट किया गया था, लेकिन ऐतिहासिक रूप से इसका उपयोग करने के लिए बेहद क्लिंकी है और दूर के हीन SQL उत्पन्न करता है। मुझे मामलों की वर्तमान स्थिति का पता नहीं है, लेकिन Microsoft ने L2S की सभी अच्छाईयों को L2EF में स्थानांतरित करने का वादा किया था, इसलिए शायद अब यह सब बेहतर है।

व्यक्तिगत रूप से, मुझे ओआरएम टूल्स के बारे में एक भावुक नापसंद है ( विवरण के लिए मेरा डायट्रीब यहां देखें), और इसलिए मुझे एल 2 एईएफ का पक्ष लेने का कोई कारण नहीं दिखता है, क्योंकि एल 2 एस मुझे देता है मुझे कभी भी एक डेटा एक्सेस लेयर की आवश्यकता होती है। वास्तव में, मुझे भी लगता है कि L2S में हैंड-क्राफ्टेड मैपिंग और इनहेरिटेंस मॉडलिंग जैसे फीचर्स पूरी तरह से अनावश्यक जटिलता जोड़ते हैं। लेकिन वह सिर्फ मैं हूं। ;-)

Comments

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

— फिनकेक

सहमत, @FNNk। यह एक दुर्भाग्यपूर्ण वास्तविकता है कि L2S का उपयोग करना कुछ जोखिम भरा है क्योंकि यह पाराया स्टेटस है। लेकिन अगर वे वास्तव में इसे L2EF के पक्ष में पूरी तरह से बंद कर देते हैं, तो मुझे दृढ़ता से संदेह है कि एक प्रवास पथ होगा, निम्नलिखित के कारण अभी भी आनंद मिलता है।

— मार्सेलो कैंटोस

लाइनक टू ईएफ परिपक्व हो गया है, और अब एल 2 एस (.NET 4.0 के रूप में) के रूप में एसक्यूएल का अच्छा उत्पादन करता है। L2EF आजकल L2S की तुलना में बहुत अच्छा है, क्योंकि यह कम से कम आपके मॉडल को DB परिवर्तनों के रूप में अपडेट कर सकता है, जो L2S कभी भी स्वचालित रूप से नहीं कर सकता। मुझे इस तथ्य को भी पसंद है कि आप साधारण एम: एम संबंधों को ईएफ के साथ एक मध्यवर्ती इकाई की आवश्यकता के बिना रिश्तों के रूप में मैप कर सकते हैं। यह कोड बनाता है कि बहुत क्लीनर।

— डेव मार्कल

अपडेट @Dave के लिए धन्यवाद। मैं हालांकि M: M टिप्पणी से असहमत हूं। मैंने जिन स्कीमाओं के साथ काम किया है, वे लगभग हमेशा अतिरिक्त तालिकाओं पर जुड़ने की क्षमता को बढ़ाते हैं। यह ऑब्जेक्ट मॉडल के लिए संरचनात्मक परिवर्तन को प्रेरित करता है, जिसके लिए बहुत सारे कोड की आवश्यकता होती है। मैं बहुत बजाय मध्यवर्ती संबंध को स्पष्ट रूप से शुरू से निपटाऊंगा।

— मार्सेलो कैंटोस

Answer 5

एक नया दृष्टिकोण है जिसे आप विचार कर सकते हैं कि आप क्या हैं और संग्रहीत प्रक्रियाओं की शक्ति और प्रदर्शन, और तेजी से विकास जो एंटिटी फ्रेमवर्क जैसे उपकरण प्रदान करते हैं।

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

इनपुट पैरामीटर एक इनपुट ऑब्जेक्ट का हिस्सा बन जाते हैं, आउटपुट पैरामीटर और परिणाम सेट एक आउटपुट ऑब्जेक्ट का हिस्सा बन जाते हैं, और एक सेवा घटक विधि कॉल प्रदान करता है।

यदि आप संग्रहीत प्रक्रियाओं का उपयोग करना चाहते हैं, लेकिन फिर भी तेजी से विकास चाहते हैं, तो आप इस सामान पर एक नज़र डालना चाहते हैं।