ओआरएम का उपयोग नहीं करने और संग्रहीत प्रक्रियाओं को प्राथमिकता देने के लिए कब?

13

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

मैं जानना चाहता हूं कि ओआरएम का उपयोग संग्रहीत प्रक्रियाओं / ट्रिगर और इसके विपरीत कब नहीं किया जाना चाहिए।

orm rdbms stored-procedures

— RPK
स्रोत

6

व्यक्तिगत रूप से ट्रिगर्स के साथ मेरी समस्या (विशेष रूप से, संग्रहीत प्रक्रियाओं पर लागू नहीं होती है) यह है कि वे "अनुमान लगाने" की कोशिश करते हैं कि डीबी पर डेटा को कैसे हेरफेर किया गया है "व्यापार कार्रवाई" क्या हुआ। यदि आप "ARTICLES" तालिका में PRICE कॉलम को संशोधित करते हैं, तो आप वास्तव में नहीं जानते कि ऐसा क्यों है। क्या उपयोगकर्ता केवल एक गलत मान को सही कर रहा है? क्या वह मार्क-डाउन है? क्या यह एक विशेष प्रस्ताव है जो केवल एक दिन के लिए रहता है? ट्रिगर को यह सब अनुमान लगाना होगा ।

— जोआचिम सॉउर

16

ORMs (ऑब्जेक्ट-रिलेशनल मैपिंग) संग्रहीत कार्यविधियों के साथ पारस्परिक रूप से अनन्य नहीं हैं। अधिकांश ओआरएम संग्रहीत प्रक्रियाओं का उपयोग कर सकते हैं। यदि आप चुनते हैं तो अधिकांश ओआरएम संग्रहित प्रक्रियाएं उत्पन्न करते हैं। तो यह मुद्दा या तो नहीं है या।

ORM अस्वीकार्य SQL उत्पन्न कर सकते हैं (प्रदर्शन के मामले में) और आप कभी-कभी उस SQL को हाथ से तैयार SQL के साथ ओवरराइड करना चाह सकते हैं। इसे पूरा करने के तरीकों में से एक एसपी (संग्रहीत प्रक्रियाओं) का उपयोग करके है।

डॉटनेट में, संग्रहीत प्रक्रियाओं का उपयोग न करें यदि:

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

ध्यान दें कि ट्रिगर्स की तुलना ORM से नहीं की जा सकती है। ट्रिगर ऐसे कार्य करते हैं जो आपके एप्लिकेशन कोड में बेहतर नहीं होते हैं (जैसे डेटाबेस में डेटा लॉग करना या सिंक्रनाइज़ करना)।

कुछ लोग सुरक्षा के लिए (उदाहरण के लिए SQL इंजेक्शन को रोकने के लिए) और उनकी दावा की गई गति के लिए कोड में SQL पर संग्रहीत कार्यविधियों के उपयोग को प्राथमिकता देते हैं। हालाँकि, यह कुछ हद तक बहस का विषय है और इस पर विस्तृत चर्चा की आवश्यकता है।

यदि आपका ORM संग्रहीत कार्यविधियाँ उत्पन्न नहीं कर सकता है, और आपको एक बड़ी प्रणाली लिखनी है, तो आपको अपने मामले के आधार पर अतिरिक्त हाथ कोडिंग का वजन करने की आवश्यकता है।

— कोई मौका नहीं
स्रोत

2

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

— आर्सेनी मौरज़ेंको

@ मेनमा, आपकी टिप्पणी के लिए धन्यवाद। मैं समझता हूँ कि एस.पी. का उपयोग कर, एक एसक्यूएल इंजेक्शन का खतरा parameterized संग्रहीत प्रक्रिया के उपयोग के द्वारा एम्बेडेड मानकों के साथ कम हो सकता है इस लेख के रूप में पता चलता है: palpapers.plynt.com/issues/2006Jun/injection-stored-procedures

— NoChance

2

संग्रहीत प्रक्रियाओं का वस्तुतः sql इंजेक्शन हमलों की भेद्यता पर कोई प्रभाव नहीं है। पुराने मिथक कठिन मर जाते हैं।

— रिग

@ रीग 1, आपकी टिप्पणी के लिए धन्यवाद, मैं इस बारे में अधिक जानने की इच्छा रखता हूं कि आप इसके बारे में क्या सोचते हैं। मेरी समझ इस पाठ (कम से कम) से आती है: "आप संग्रहीत कार्यविधियों का उपयोग करके SQL सर्वर इंजेक्शन के हमलों को कम कर सकते हैं और डायनामिक SQL से बच सकते हैं, और सभी उपयोगकर्ताओं पर अनुमतियों को प्रतिबंधित कर सकते हैं।" यह msdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance

@EmmadKareem Parameterized sql इसे सुरक्षित बनाने के लिए एक बड़ा कदम है। मुझे लगता है कि यह लड़का एक उचित मामला बनाता है palpapers.plynt.com/issues/2006Jun/injection-stored-procedures । इस पर एक खोज "संग्रहीत प्रक्रिया एसक्यूएल इंजेक्शन" बहुत हिट हो जाएगी। अपने इनपुट्स को सैनिटाइज़ करना हमेशा अच्छा होता है और बहुत सारे प्लेटफ़ॉर्म इसे यथोचित रूप से करने के लिए एक अंतर्निहित तरीका प्रदान करते हैं।

— रिग

13

ORM अक्सर मान लेते हैं कि ORM की सेवा के लिए डेटाबेस मौजूद है। लेकिन आमतौर पर डेटाबेस कंपनी की सेवा के लिए मौजूद होता है, जिसमें कई भाषाओं में लिखे सैकड़ों और सैकड़ों ऐप हो सकते हैं।

लेकिन यह केवल "ORM बनाम संग्रहीत कार्यविधियाँ" का मामला है यदि आप एक ORM का उपयोग कर रहे हैं जो किसी संग्रहीत कार्यविधि को कॉल नहीं कर सकता है। अन्यथा, यह निर्णय लेने का मामला है कि व्यापारिक तर्क को कहां कोडित किया जाए।

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

यदि आप "अभेद्य" DAL का उपयोग करते हैं तो dbms कमांड-लाइन इंटरफ़ेस से सावधान रहें।

— माइक शेरिल 'कैट रिकॉल'
स्रोत

4

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

— jfrankcarr

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

— फ्लाटर

-1

सरल क्वेरी -> ORM

जटिल प्रश्न -> संग्रहित प्रक्रिया

— अँधेरी रात
स्रोत

3

एक सरल प्रश्न से एक जटिल अलग कहाँ जाता है,

— स्वतंत्र

-2

ट्रिगर का उपयोग रिकॉर्ड के अपरिवर्तनीय के रूप में किया जाना चाहिए या महत्वपूर्ण व्यावसायिक नियमों से युक्त होना चाहिए, IMHO।

Orms की समस्याएँ:

आपको "एक्शन" के अनुसार प्रति टेबल अनुमतियाँ सेट करनी चाहिए (मेरा मतलब है कि SP)
अपने समाधान के तर्क को बदलने के लिए आपको अपने ऐप के अंदर कोड को बदलने की आवश्यकता है और फिर इसे क्लाइंट के लिए नेटवर्क पर फिर से वितरित करें

— यूरी विकुलोव
स्रोत

-5

सहमत नहीं हैं। ORM क्वेरी केवल सरल है यदि आप ORM को SQL से बेहतर जानते हैं। ORM अधिक कोड में परिणाम देता है, IMO को बनाए रखने के लिए कहीं अधिक कठिन। ओआरएम से लाभ पाने वाले एकमात्र लोग ओआरएम (उदाहरण के लिए माइक्रोसॉफ्ट) बेचने वाली कंपनी के शेयरधारक हैं।

— प्रेत
स्रोत

1

इस जवाब में व्यक्त की गई काफी दया न तो संदर्भों और न ही अनुभव द्वारा समर्थित है। नतीजतन, यह एक पाठक के लिए बेकार होगा जो संग्रहीत प्रक्रियाओं की तरह "उलटा" दावे पर ठोकर खा सकता है, केवल डीबी विक्रेताओं को लाभ होता है । एक एहसास क्यों में मार्गदर्शन बनाता है रियल सवाल जवाब राज्यों: "असली सवाल है, जवाब , नहीं आइटम या विचारों या राय ... "

— कुटकी