LINQ-to-SQL बनाम संग्रहीत प्रक्रियाओं?



Answers

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

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

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

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

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

Question

मैंने स्टैक ओवरव्लो ( LINQ के शुरुआती गाइड ) पर "शुरुआती गाइड टू LINQ" पोस्ट पर एक नज़र डाली, लेकिन एक फॉलो-अप प्रश्न था:

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

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

धन्यवाद।




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




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

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







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

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

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




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

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

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

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

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

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

LINQ के साथ टीएसक्यूएल सीखना नहीं है: नहीं, आप नहीं करते हैं, लेकिन आपको LINQ सीखना है - लाभ कहां है?

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

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

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

संपादित करें: LINQ से एसक्यूएल संग्रहीत प्रक्रिया चीजों की चीज कुछ है जो मुझे अभी भी पढ़ने की जरूरत है - मुझे जो मिलता है उसके आधार पर मैं अपने उपरोक्त डायरी को बदल सकता हूं;)




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

लिंकक में जाने के बाद से मुझे निम्नलिखित फायदे मिल गए हैं:

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



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

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




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




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




मुझे लगता है कि आपको वास्तविक चीज़ों के लिए प्रोसेस के साथ जाना होगा।

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

बी) मुझे विश्वास नहीं है कि ऑब्जेक्ट मॉडलिंग वैसे भी संबंधपरक मॉडलिंग से बेहतर है।

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

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

ई) लिंक से एसक्यूएल अभी भी क्रैपी कोड लिखता है जब आप इसकी अपेक्षा नहीं करते हैं।

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




Related