अपने कोड में संग्रहीत SQL प्रश्नों को व्यवस्थित करने का सबसे अच्छा तरीका है? (या आपको चाहिए?) [बंद]

Question

मुझे यकीन है कि मैं अकेला नहीं हूं जो SQL प्रश्नों के साथ कोडित का एक पृष्ठ देखने पर निराश हो जाता है। ActiveRecord और अन्य ORM पैटर्न किसी प्रोजेक्ट में उपयोग की जाने वाली SQL की एक अच्छी मात्रा को कम करने में मदद करते हैं, लेकिन जटिल प्रश्नों के कई मामलों में, SQL का उपयोग अनुपयोगी प्रतीत होता है।

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

EDIT 1 - मैं मान रहा हूं कि आप पहले ही इसे मॉडल लेयर में अलग कर चुके हैं

Comments

यह प्रश्न यहाँ निश्चित रूप से उचित है - कोड संगठन: '[s] उत्तर देते हैं कि "क्यों" और "कैसे" समझाएँ।' और विषयों के 'डिजाइन पैटर्न' और 'वास्तुकला' ( Faq से ) है

— माइकल के

मैं बस यही सवाल पूछने वाला था। काश कि यहां और भी उत्तर होते।

— माइकल क्रिस्टोफिक

Answer 1

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

जैसा कि मैं इसे देखता हूं, डेटा पढ़ना, डेटा प्रोसेसिंग करना, डेटा लिखना, डेटा खोजना ... वे सभी समान ऑपरेशन हैं, और सबसे अच्छी तरह से एक ही स्थान पर रखे गए हैं।

यदि आप प्रश्नों के साथ प्रयासों के दोहराव को महसूस करना शुरू करते हैं, तो शायद आपको डेटाबेस दृश्य या एक ऐसी वस्तु की आवश्यकता है जो डेटाबेस एक्सेस के उस पहलू को बाधित कर सके।

एक और टिप वास्तव में एक अच्छा डेटाबेस क्वेरी विधि है। सॉफ्टवेयर में मैं लिखता हूं (PostgreSQL, MySQL, SQL सर्वर), मैंने यह सुनिश्चित किया है कि मेरे क्वेरी संचालन के थोक कोड के एक बयान के रूप में हो सकते हैं।

GetValue(SQL, [transaction], [array_of_params])
GetRow(SQL, [transaction], [array_of_params])
GetRowList(SQL, [transaction], [array_of_params])
GetValueList(SQL, [transaction], [array_of_params])
Execute(SQL, [transaction], [array_of_params])

वे (मोटे तौर पर) मुख्य फ़ंक्शन कॉल हैं जो मुझे सुनिश्चित करते हैं कि मेरे "कनेक्शन ऑब्जेक्ट" का हिस्सा हैं। यह भाषा पर निर्भर करता है कि आप वास्तव में क्या लागू करते हैं, लेकिन मेरा कहना है कि इसे वास्तव में, वास्तव में सरल और दर्द रहित रखना है।

सारांश में, SQL को प्रोग्रामिंग का मूल भाग मानें, और अमूर्तता के लिए अमूर्त न करें।

Comments

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

— जेलिफ़िश्री

"अमूर्त के लिए सार मत करो" - अच्छी बात है। अधिक समझने योग्य कोड के लिए सार।

— जेसन बेकर

'एक और टिप वास्तव में एक अच्छा डेटाबेस क्वेरी विधि है': मैं निश्चित रूप से सहमत हूं। जब व्यापार तर्क बदलता है तो कोड को संशोधित करने के लिए केवल एक ही स्थान होने पर यह बहुत मदद करता है।

— माइकल के

आप एसक्यूएल कहाँ लगाते हैं? क्या यह आवेदन में संकलित है और उपरोक्त विधियों का उपयोग करके भेजा गया है?

— जॉनी

जेसन बेकर के जवाब पर ओपी द्वारा टिप्पणी के आधार पर, "एक विशाल एसक्यूएल क्वेरी के बैरल को घूरते हुए ...", यह एसक्यूएल पाठ के बड़े ब्लॉकों को पढ़ने की समस्या को कैसे संबोधित करता है?

— जेएफओ

Answer 2

आमतौर पर, एक अलग मॉडल परत का होना सबसे अच्छा तरीका है। कई उद्यम डिजाइन पैटर्न हैं जो इसे आर्किटेक्ट करने के तरीके देते हैं।

Comments

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

— jellyfishtree

@ जेलीफ़िशट्री - मुझे डर है कि मुझे समझ में नहीं आता कि समस्या क्या है। मेरा मतलब है, आपको डर है कि आपकी मॉडल परत बहुत अधिक मॉडल कोड के साथ समाप्त हो सकती है?

— जेसन बेकर

एक वैध खंडन। मुझे पठनीयता की चिंता है। अच्छा मॉडल कोड आमतौर पर समझने में बहुत आसान होता है, लेकिन एक विशालकाय SQL क्वेरी के बैरल को घूरने से इसका अर्थ बिल्कुल नहीं निकलता है। जाहिर है कि पहली बात यह है कि उन प्रश्नों पर ठीक से टिप्पणी की जाए, लेकिन यह उतना अच्छा नहीं है, स्व-दस्तावेज कोड और इस प्रकार के खंड पूरे मॉडल में बिखरे हुए हैं। मैं इसे स्वीकार करता हूं, लेकिन मैं सोच रहा था कि क्या मॉडल में पागल एसक्यूएल बयानों को अलग करने या व्यवस्थित करने का एक बेहतर तरीका है ...

— jellyfishtree

Answer 3

अपने मॉडल लेयर को 3 उप-लेयर्स - "एंटिटीज़", "रिपॉजिटरी" और "सर्विसेज" में अलग करना अच्छा हो सकता है। यह आपको चिंताओं को अलग करने और SQL को एक स्थान पर इकट्ठा करने, आपके व्यावसायिक तर्क से बाहर कर देगा।

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

गेटिअर्स और सेटर के साथ एंटिटी एब्स्ट्रैक्ट्स असली डीबी टेबल फील्ड नाम, आपके एप्लिकेशन / प्रोग्रामिंग भाषा में उपलब्ध डीबी फील्ड प्रकारों और प्रकारों के बीच कुछ डेटा रूपांतरण प्रदान कर सकते हैं। यदि आपका ORM समर्थन करता है - संस्थाएँ संघों को संभाल सकती हैं।

सेवा की परत व्यावसायिक तर्क के लिए जगह है। सेवा रिपॉजिटरी का उपयोग करके संस्थाओं को पुनः प्राप्त करती है, उन पर कार्रवाई करती है और उन्हें वापस स्टोर करती है।