SQL क्वेरी बिल्डरों का उपयोग करने के क्या फायदे हैं?

Question

कच्चे SQL का उपयोग करने के बजाय किसी क्वेरी बिल्डर का उपयोग करने के कोई फायदे हैं?

उदाहरण के लिए

$q->select('*')
  ->from('posts')
  ->innerJoin('terms', 'post_id')
  ->where(...)

बनाम:

SELECT * FROM posts WHERE ...

मैं देखता हूं कि कई ढांचे इस तरह की अमूर्त परतों का उपयोग करते हैं, लेकिन मैं लाभों को समझने में विफल रहता हूं।

Comments

मुझे लगता है कि किसी को विचारों के विरुद्ध प्रश्न लिखना चाहिए न कि तालिकाओं के विरुद्ध। मुझे लगता है कि जो लोग क्वेरी बिल्डरों का उपयोग करते हैं, वे विचार नहीं लिखते हैं या डीबीए को उनके लिए बनाने के लिए कहते हैं। ऐसा करने में वे RDBMS की सारी शक्ति का लाभ नहीं उठाते हैं।

— ट्यूलेंस कोरडोवा

@ user61852: संभवत: कुछ सुरक्षा और मुफ्त में फ़िल्टर करने के अलावा, विचारों के विरुद्ध प्रश्न क्या प्रदान कर सकते हैं जो तालिकाओं के विरुद्ध प्रश्न भी प्रदान नहीं कर सकते हैं?

— रॉबर्ट हार्वे

@RobertHarvey एक ही बात है कि कंक्रीट कक्षाओं के बजाय इंटरफेस के लिए प्रोग्रामिंग। Decoupling और लचीलापन। अंतर्निहित तालिकाओं का डिज़ाइन "अनुबंध" के रूप में लंबे समय तक मौका दे सकता है, दृश्य, हमेशा की तरह "कॉलम" का अनुकरण करता है।

— ट्यूलेंस कोर्डोवा

@ user61852 मेला पर्याप्त

— रॉबर्ट हार्वे

@RobertHarvey मैंने उसे एक उत्तर में बदल दिया।

— तुलसी कोर्डोवा

Answer 1

अच्छी तरह से एक फ्रेमवर्क के माध्यम से एसक्यूएल लिखने का अमूर्त, अमूर्त।

एसक्यूएल को हाथ से लिखना अपने आप में यह सब बुरा नहीं है, लेकिन आप पलायन और सफाई के साथ मुद्दों को प्राप्त करना शुरू करते हैं और यह एक गड़बड़ में बदल जाता है। एक एब्सट्रैक्शन लेयर पर्दे के पीछे आपके कोड को साफ और बहुत सारी mysql_real_escape_string()कॉल या लाइक से मुक्त करने की अनुमति देती है।

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

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

Comments

मुझे नहीं लगता कि SQL बोलियाँ RDBMSes में भिन्न हैं। और PHP में PDO है जो u

— अन्ना के।

SQL बोलियाँ भिन्न होती हैं, इसीलिए उन्हें बोलियाँ कहा जाता है। पीडीओ के लिए, अमूर्त परत बस इस गंदगी को हमसे छिपाती है।

@GlennNelson अन्ना का मतलब किसी एक बोली, विभिन्न बैकेंड्स (PSQL / MySQL / SQLite ...) का उपयोग करना है

— इज़काता

@AnnaK। बोली भले ही न बदले, लेकिन कभी-कभी सुविधाएँ भिन्न होती हैं। उदाहरण के लिए, MySQL (MyISAM इंजन के साथ) विदेशी कुंजी प्रतिबंधों का समर्थन नहीं करता है, जबकि PostGres करता है। या तो बोली को खुद को संभालना होगा (जिसमें डेटा संरचना की पूरी जानकारी की आवश्यकता होती है, जैसे कि Django ORM करता है), या, अधिक संभावना: उपयोगकर्ता को इसके बारे में स्मार्ट होना होगा कि वे इसका उपयोग कैसे करते हैं, जो इसे देख सकता है। परिस्थितियों के आधार पर बोली में परिवर्तन होता है।

— इज़काता

एक अच्छी तरह से निर्मित टूल को आपके भागने और आपके लिए स्वच्छता बनाने के लिए +1। यदि यह वैधीकरण भी कर सकता है, तो और भी बेहतर।

— डैन रे

Answer 2

क्वेरी बिल्डर्स मेरे लिए एक पालतू पशु से नफरत करते हैं, इसलिए मैंने उन्हें उपयोग करने से बचने के लिए अपना स्वयं का फ्रेमवर्क (एपेल) लिखा!

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

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

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

क्वेरी बिल्डर के qwirks के साथ पकड़ में आने में लगने वाला समय (तब जब आप बेहतर तरीके से स्विच करते हैं तो फिर से सीखना) आपके एसक्यूएल को ऑप्टिमाइज़ करने के तरीके को सीखने में कहीं अधिक खर्च होगा।

वैसे भी यही कारण है कि एक का उपयोग करने के लिए नहीं, कुछ लोग उन्हें प्यार करते हैं।

Answer 3

सैद्धांतिक रूप से? हाँ। ग्लेन नेल्सन ने बताया कैसे वे अक्सर आपकी मदद करेंगे। (यदि यह एक अच्छा क्वेरी बिल्डर है)।

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

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

Comments

क्या डीबी क्विक स्थिति जैसी कोई चीज़ पहले से हल नहीं होनी चाहिए? मेरा मतलब यह है कि आपके ग्राहक डीबी का उपयोग क्या कर रहे हैं और उचित रूपरेखाओं / पुस्तकालयों का चयन कर रहे हैं तदनुसार यह कुछ ऐसा है जिसे कोड की एक पंक्ति लिखने से पहले आपको संभालना चाहिए ।

Answer 4

मुझे लगता है कि क्वेरी बिल्डर का व्यावहारिक, दिन-प्रतिदिन लाभ - कोड का पुन: उपयोग और DRY सिद्धांत का पालन करने की क्षमता है।

क्वेरी बिल्डर के साथ आप SQL के कुछ हिस्सों को दोहरा सकते हैं। और फिर जटिल SQL रचना के लिए इन विधियों का उपयोग करें। एक उदाहरण उदाहरण के लिए पुन: प्रयोज्य जॉय खंड होगा:

function joinTaskWithClient($queryBuilder) {
    $queryBuilder->join('task', 'contract', 'task.contract_id = contract.id')
                 ->join('contract', 'client', 'contract.client_id = client.id');
}

तो उपयोग होगा:

$queryBuilder->select('client.name')
             ->from('client')
             ->where('task.id=:task')->setParameter('task', 42);
joinTaskWithClient($queryBuilder);

जैसा कि आप नोट कर सकते हैं - क्वेरी बिल्डर के साथ आप SQL स्ट्रिंग के किसी भी क्रम में जोड़ सकते हैं (उदाहरण के लिए इसमें एक के बाद भाग जोड़ें) जब आप SQL स्ट्रिंग को मैन्युअल रूप से इकट्ठा करते हैं। इसके अलावा, आप इसके इरादे और लाभों को देखने के लिए बिल्डर पैटर्न के बारे में पढ़ सकते हैं ।

मैं भागने और स्वच्छता के बारे में सहमत हूं, लेकिन यह w / o क्वेरी बिल्डर के रूप में अच्छी तरह से प्राप्त किया जा सकता है। DB प्रकार / बोली अमूर्त के बारे में - यह काफी सैद्धांतिक और संदिग्ध लाभ है, शायद ही कभी अभ्यास में उपयोग किया जाता है।

Comments

मेरे लिए, यह भी एक मुख्य लाभ है। एक और यह है कि तरीकों में अमूर्त करने से आप विधियों को अधिक सार्थक नाम दे सकते हैं और यहां तक ​​कि इससे एक डोमेन विशिष्ट भाषा भी बना सकते हैं, जिससे इरादा बहुत अधिक स्पष्ट हो जाता है। आप क्वेरी बिल्डर को भी पास कर सकते हैं और विभिन्न घटकों को इसमें विशिष्ट बिट्स जोड़ सकते हैं। पिछले नहीं बल्कि कम से कम मैंने पाया कि मुझे सार्थक-नामित विधियों के पीछे पैटर्न को एनकैप्सुलेट करने की अनुमति दी गई है .... मैंने कुछ क्वेरी बिल्डरों को पाया है जहां पहले वाले कॉलमों को बेवकूफी से जोड़ दिया गया था, जो ऊपर दिए गए बेकार के बहुत सारे

— प्रतिपादन करता है

Answer 5

मैं मेरा ( बोली ) एक कस्टम SQL बिल्डर की readme फ़ाइल के आधार पर एक उत्तर प्रदान करेगा

(सादा पाठ इस प्रकार है, हटाए गए पुस्तकालय-विशिष्ट संदर्भ)

आवश्यकताएँ

1. कई DB विक्रेताओं (जैसे। MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, ..) का समर्थन करें।
2. आसानी से नए डीबी तक विस्तारित (अधिमानतः, कार्यान्वयन-स्वतंत्र, कॉन्फ़िगर सेटिंग के माध्यम से)
3. प्रतिरूपकता और कार्यान्वयन-स्वतंत्र हस्तांतरणीयता
4. लचीला और सहज एपीआई

विशेषताएं

1. व्याकरण-आधारित टेम्पलेट
2. कस्टम नरम विचारों का समर्थन करते हैं
3. DB अमूर्तता, प्रतिरूपकता और हस्तांतरणीयता
4. तैयार किए गए टेम्प्लेट
5. डेटा बच रहा है

मुझे लगता है कि उपरोक्त सुविधाओं और आवश्यकताओं के कारण स्केच एक एसक्यूएल अमूर्त बिल्डर का उपयोग करेगा

उपरोक्त सुविधाओं में से अधिकांश एसक्यूएल बिल्डरों द्वारा समर्थित हैं (हालांकि मुझे नहीं लगता कि सभी सूचीबद्ध मेरे ज्ञान के लिए समर्थित हैं)

उपयोग के मामले उदाहरण:

1. CMS मंच कई DB विक्रेताओं के साथ काम करने में सक्षम है (अंतर्निहित कोड के परिवर्तन नहीं)
2. कस्टम एप्लिकेशन कोड जहां DB विक्रेता को बदलने के लिए उपयुक्त है और / या dB स्कीमा गतिशील हैं (इसका मतलब है कि कई प्रश्नों को हार्ड-कोडित नहीं किया जा सकता है लेकिन फिर भी पर्याप्त सार करने की आवश्यकता है इसलिए कोड परिवर्तन के लिए मजबूत है)
3. उत्पादन में प्रयुक्त एक से अधिक DB के साथ प्रोटोटाइप (कुछ कोड के लिए कम से कम डुप्लिकेट कोड आधार की आवश्यकता होगी)
4. एप्लिकेशन कोड कसकर युग्मित नहीं है विशिष्ट DB प्रदाता और / या कार्यान्वयन लिए (यहां तक ​​कि एक ही DB विक्रेता, जैसे DB विक्रेता के विभिन्न संस्करण), इस प्रकार अधिक मजबूत, लचीला और मॉड्यूलर है
5. प्रश्नों और डेटा से बचने के कई सामान्य मामलों को फ्रेमवर्क द्वारा ही नियंत्रित किया जाता है और सामान्य रूप से यह इष्टतम और तेज दोनों है

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

उस मामले में एक एमवीसी जैसा आवेदन करने में सक्षम होने के कारण जहां मॉडल को कस्टम / डायनामिक स्थितियों द्वारा क्वेरी किया जा सकता है, जिससे क्वेरी को लगभग एक दुःस्वप्न के रूप में हार्ड-कोडिंग किया जा सकता है। कल्पना करें कि जुड़वाओं के साथ 2-3 टेबल तक का समर्थन करना संभव है और शर्तों को छानने के लिए कि किस तालिका को किसके साथ जुड़ना है और साथ ही आवश्यक एलियास का ख्याल रखना है।

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

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

देखो मेरा मतलब है?

Answer 6

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

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

Answer 7

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

ऐसे क्वेरी बिल्डरों का उपयोग करना अच्छा है , लेकिन मुझे लगता है कि जो लोग उन पर बहुत भरोसा करते हैं, वे डीबीए से यह नहीं पूछते हैं: "अरे, यह एक क्वेरी है जिसका मैं बहुत उपयोग करता हूं, कृपया इससे एक दृश्य बनाएं"।

मुझे गलत मत समझो

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

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

क्या मैं यह सोचने में गलत हूं कि प्रश्नों को नहीं लिखने से आप कुछ विचारों को बनाने की आवश्यकता का पता लगाने में विफल रहते हैं?

एक और बात जो मुझे चिंतित करती है वह है नौसिखिए प्रोग्रामर का SQL में महारत हासिल न करना, जो कि इंसान द्वारा बनाई गई सबसे सुंदर तकनीक में से एक है, ऐसा न करने से।

Comments

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

— जेएफओ

यह कुल अलग स्थिति है, और पूरी तरह से ठीक है।

— ट्यूलेंस कोर्डोवा

मुझे लगता है कि डीबीए को शामिल करने से हर बार ऐसा लगता है कि जब कोई तालिका किसी एकल रिकॉर्ड को खींचती है या विकास प्रक्रिया में एक अड़चन पैदा करती है।

— जेएफओ