जावा प्रोग्रामिंग - एसक्यूएल स्टेटमेंट्स कहां संग्रहीत किए जाने चाहिए? [बन्द है]

Question

JDBC-compliant एप्लिकेशन को अपने एसक्यूएल स्टेटमेंट को कहां और क्यों स्टोर करना चाहिए?

अब तक, मैं इन विकल्पों की पहचान करने में कामयाब रहा:

• व्यावसायिक वस्तुओं में हार्डकोड
• SQLJ खंडों में एंबेडेड
• डेटा एक्सेस ऑब्जेक्ट्स जैसे अलग-अलग कक्षाओं में इनकैप्सुलेट
• मेटाडेटा चालित (डेटा स्कीमा से ऑब्जेक्ट स्कीमा को कम करें - मेटाडेटा में उनके बीच की मैपिंग का वर्णन करें)
• बाहरी फ़ाइलें (उदाहरण के लिए गुण या संसाधन फ़ाइलें)
• संग्रहित प्रक्रियाएं

हर एक के लिए "पेशेवरों" और "विपक्ष" क्या हैं?

SQL कोड को "कोड" या "मेटाडेटा" माना जाना चाहिए?

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

क्या प्रदर्शन एक महत्वपूर्ण कारक है? विक्रेता लॉक-इन के बारे में क्या ?

क्या बेहतर है - ढीली युग्मन या तंग युग्मन और क्यों?

EDITED: जवाब के लिए आप सभी को धन्यवाद - यहाँ एक सारांश है:

मेटाडाटा संचालित अर्थात वस्तु संबंधपरक मैपिंग (ओआरएम)

पेशेवरों:

• बहुत सार - DB सर्वर को मॉडल को बदलने की आवश्यकता के बिना स्विच किया जा सकता है
• वाइड-स्प्रेड - व्यावहारिक रूप से एक मानक
• SQL की मात्रा को कम करता है
• संसाधन फ़ाइलों में SQL संग्रहीत कर सकते हैं
• प्रदर्शन (आमतौर पर) स्वीकार्य है
• मेटाडेटा संचालित दृष्टिकोण
• (डेटाबेस) विक्रेता स्वतंत्रता

विपक्ष:

• SQL और सच्चे डेवलपर्स इरादों को छुपाता है
• DBA द्वारा समीक्षा की गई / परिवर्तित की जाने वाली SQL मुश्किल
• SQL को अभी भी विषम मामलों के लिए आवश्यक हो सकता है
• एक स्वामित्व क्वेरी भाषा जैसे HQL के उपयोग को मजबूर कर सकता है
• अनुकूलन (अमूर्तता) के लिए खुद को उधार नहीं देता है
• संदर्भात्मक अखंडता की कमी हो सकती है
• SQL ज्ञान की कमी या DB में कोड की देखभाल की कमी के लिए सदस्यता
• मूल डेटाबेस प्रदर्शन से कभी मेल न करें (भले ही वह करीब आए)
• मॉडल कोड डेटाबेस मॉडल के साथ बहुत तंग है

DAO परत में हार्डकोडेड / एनकैप्सुलेटेड

पेशेवरों:

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

विपक्ष:

• SQL की DBA द्वारा समीक्षा / परिवर्तन नहीं किया जा सकता है
• एसक्यूएल डीबी-विशिष्ट बनने की संभावना है
• एसक्यूएल बनाए रखने के लिए कठिन हो सकता है

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

पेशेवरों:

• SQL डेटाबेस में रखा (डेटा के करीब)
• SQL को DBMS द्वारा पार्स, संकलित और अनुकूलित किया गया है
• SQL DBA की समीक्षा / परिवर्तन के लिए आसान है
• नेटवर्क ट्रैफ़िक को कम करता है
• सुरक्षा बढ़ा दी

विपक्ष:

• SQL डेटाबेस (विक्रेता लॉक-इन) से बंधा हुआ है
• SQL कोड बनाए रखने के लिए कठिन है

बाहरी फ़ाइलें (उदाहरण के लिए गुण या संसाधन फ़ाइलें)

पेशेवरों

• SQL को एप्लिकेशन के पुनर्निर्माण की आवश्यकता के बिना बदला जा सकता है
• अनुप्रयोग व्यवसाय तर्क से SQL तर्क को कम करता है
• सभी एसक्यूएल बयानों के केंद्रीय भंडार - बनाए रखने के लिए आसान
• समझने में आसान

विपक्ष:

• SQL कोड अप्राप्य हो सकता है
• (सिंटैक्स) त्रुटियों के लिए SQL कोड की जाँच करने के लिए कठिन

SQLJ खंडों में एंबेडेड

पेशेवरों:

• बेहतर वाक्यविन्यास जाँच

विपक्ष:

• जावा के बहुत करीब है
• JDBC की तुलना में कम प्रदर्शन
• गतिशील प्रश्नों का अभाव
• इतना लोकप्रिय नहीं है

Comments

अच्छे सवाल लेकिन शायद एक ही बार में सभी का जवाब देने के लिए थोड़ा बहुत। इन सभी imho: p

— NickDK

+1 अच्छा सवाल! आपको @ ORDecio प्रति "ORM" जोड़ना चाहिए। इसके अलावा "अपने जावा कोड में हर जगह छिड़का हुआ" (जो मैंने देखा है और सबसे खराब होना है) जोड़ें।

— जिम फेर्र्स

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

— माइकल लॉयड ली mlk

मेरी राय में, आपने एक विकल्प याद किया है: विचारों का उपयोग। आप जटिल एसक्यूएल को विचारों में व्यक्त कर सकते हैं और फिर उन दृश्यों पर सरल चयन व्यक्त कर सकते हैं (किसी भी प्रकार के अमूर्त का उपयोग कर: DAO, SQLJ, ORM's, आदि)। आपके पास संग्रहीत कार्यविधियों के समान ही मुकदमे होंगे, लेकिन मुझे नहीं लगता कि आपके पास उनकी कोई विपक्ष होगी ...

— लुकास ईडर

Answer 1

आमतौर पर, आकार और / या पुन: प्रयोज्य के संदर्भ में जितना अधिक आवेदन बढ़ता है, उतनी ही आवश्यकता SQL बयानों को बाहरी / सार करने के लिए होती है।

हार्डकोड (स्थिर अंतिम स्थिरांक के रूप में) पहला कदम है। एक फ़ाइल में संग्रहीत (गुण / xml फ़ाइल) अगला चरण है। मेटाडेटा चालित (जैसा कि एक ORM जैसे हाइबरनेट / JPA द्वारा किया जाता है) अंतिम चरण है।

हार्डकोड का नुकसान यह है कि आपका कोड डीबी-विशिष्ट बनने की संभावना है और आपको प्रत्येक परिवर्तन पर पुनर्लेखन / पुनर्निर्माण / पुनर्वितरण करने की आवश्यकता है। फायदा यह है कि आपके पास 1 जगह है।

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

मेटाडेटा द्वारा संचालित नुकसान यह है कि आपका मॉडल कोड डेटाबेस मॉडल के साथ बहुत तंग है। डेटाबेस मॉडल में हर बदलाव के लिए आपको कोड को फिर से लिखना / पुनर्निर्माण / पुनर्वितरित करना होगा। फायदा यह है कि यह बहुत सार है और आप अपने मॉडल को बदलने की आवश्यकता के बिना आसानी से डीबी सर्वर से स्विच कर सकते हैं (लेकिन अब खुद से पूछें: डीबी सर्वर से कंपनी कितनी बार स्विच करेगी? संभावना है कि कम से कम केवल 3 साल में एक बार, isn ' टी;)।

मैं संग्रहीत प्रक्रियाओं को इसके लिए "अच्छा" समाधान नहीं कहूंगा। उनका एक अलग उद्देश्य है। हालांकि, आपका कोड उपयोग किए गए DB / कॉन्फ़िगरेशन पर निर्भर करेगा।

Answer 2

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

Comments

यह शायद इष्टतम नहीं है, लेकिन यह वही है जो मैं भी करता हूं। लिखने में आसान, नीचे ट्रैक करने में आसान और चिंता करने के लिए कोई गन्दा आर्किटेक्चर नहीं।

— जेम्स क्रोनेन

और हार्ड-कोडेड SQL को ट्रैक करने में बिताया गया हर समय नौकरी की सुरक्षा है। यदि आप एकमात्र व्यक्ति हैं जो जानते हैं कि SQL कहाँ है, तो आपको निकाल नहीं दिया जा सकता है।

— S.Lott

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

— डैनियल प्राइडेन

-1। DAO रखना ठीक है लेकिन बहुत कम से कम प्रश्नों को एक संपत्ति फ़ाइल में स्थानांतरित करें ताकि DBA समीक्षा कर सके और उन्हें उचित रूप में ट्विक कर सके!

— cethegeek

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

— जेसन ग्रिटमैन

Answer 3

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

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

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

अब हम संग्रहीत प्रक्रियाओं का उपयोग करते हैं (कॉल स्टेटमेंट हार्डकोड के साथ)। अब पहली बात यह है कि हर कोई शिकायत करेगा कि आप डेटाबेस से बंधे हैं। तुम हो। हालाँकि आपने कितनी बार डेटाबेस बदला है? मैं इस तथ्य के लिए जानता हूं कि हम केवल इसका प्रयास भी नहीं कर सकते हैं, इस पर निर्भर अन्य कोड की मात्रा हमारे DBAs को पुनः प्राप्त करने के साथ-साथ डेटा को माइग्रेट कर रही है। यह बहुत महंगा ऑपरेशन होगा। हालांकि अगर आपकी दुनिया में एक टोपी की एक बूंद में DBs बदलना आवश्यक है तो SP की संभावना है।

आगे जाकर मैं ओरेकल पैकेज से जावा कक्षाएं बनाने के लिए कोड जनरेशन टूल्स के साथ संग्रहीत प्रक्रियाओं का उपयोग करना चाहूंगा।

2013-01-31 को संपादित करें : कुछ साल और डीबीए बाद में और अब हम हाइबरनेट का उपयोग करते हैं, SQL में जा रहे हैं (डीबी में संग्रहीत प्रोक्स) केवल जब बिल्कुल आवश्यक हो। मुझे लगता है कि यह सबसे अच्छा उपाय है। 99% बार DBs को SQL के बारे में चिंता करने की आवश्यकता नहीं होती है, और 1% वे ऐसा करते हैं वे एक ऐसी जगह पर हैं जहां वे पहले से ही आरामदायक हैं।

Comments

संग्रहीत प्रक्रियाओं को लिखने और फिर उनसे जावा कोड तैयार करने के विचार के लिए +1, अन्य तरीके से नहीं।

— डैनियल प्रीडेन

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

— 18

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

— डैनियल प्राइडेन

आपको jooq.org का उपयोग करने में रुचि हो सकती है । यह वही है जो आपने कहा था: "ओरेकल पैकेज से जावा कक्षाएं बनाने के लिए कोड पीढ़ी"। इसके अलावा, यह SQL # जैसे DSL के साथ जहाज करता है, C # में LINQ के समान है, तो क्या आपको जावा में SQL को व्यक्त करने की आवश्यकता है, जिसे आप किसी संग्रहीत प्रक्रिया के अंदर नहीं डाल सकते।

— लुकास ईडर

Answer 4

ORM (जैसे हाइबरनेट) का उपयोग करके आप उम्मीद करते हैं कि आपको चिंता करने के लिए कोई SQL कथन नहीं होगा । प्रदर्शन आमतौर पर स्वीकार्य है और आपको विक्रेता स्वतंत्रता भी मिलती है।

Comments

-1 आपके पास एचक्यूएल स्टेटमेंट होंगे और अधिकांश मुद्दे एचक्यूएल के बारे में बने रहेंगे। क्या वे कोड (स्ट्रिंग शाब्दिक) के अंदर होंगे, एनोटेशन में प्रश्नों का नाम, xml फ़ाइलों में नामित क्वेरीज़, गुण फ़ाइलों में संग्रहीत?

— फ्लाईबवायर

@flybywire - हाइबरनेट के साथ यह HQL का सहारा लेना दुर्लभ है। 98% मामलों के लिए, उदाहरण के लिए और मानदंड (जैसे वस्तुओं का उपयोग करके) कि सभी की जरूरत है।

— एकलशॉट

@SingleShot, मैं सहमत नहीं हूँ। यदि यह आईडी द्वारा चयन की तुलना में कुछ अधिक जटिल है, मुझे लगता है कि यह HQL के साथ किया जाता है। मैं कहूंगा कि मानदंड और उदाहरण का उपयोग तब किया जाता है जब उपयोगकर्ता-इंटरफ़ेस संचालित खोज एक लाइब्रेरी कैटलॉग में खोज स्क्रीन के रूप में होती है। लेकिन आइए देखें कि दूसरे क्या सोचते हैं।

— फ्लाईबवायर

@SingleShot - मैं बहुत असहमत हूं। हम एचक्यूएल का बहुत उपयोग करते हैं, विशेषकर प्रश्नों की रिपोर्टिंग के लिए। कुछ HQL विशेषताओं को मापदंड द्वारा बिल्कुल भी समर्थित नहीं किया गया है (कस्टम SQL फ़ंक्शंस का उपयोग करके, चुनिंदा खंड में कन्स्ट्रक्टर)। क्यूबीई कभी-कभी अधिक समस्याओं का कारण बन सकता है तो यह हल करता है।

— javashlook

"हाइबरनेट के साथ यह HQL का सहारा लेने के लिए एक दुर्लभ वस्तु है" आज तक मैंने जो सबसे मजेदार बात सुनी है। QBE हास्यास्पद है; और जब तक आपको UI प्रश्नों के लिए मानदंड का सहारा लेना पड़ सकता है , अच्छी तरह से परिभाषित प्रश्न (रिपोर्टिंग / सेवा इंटरैक्शन / आदि ...) सभी HQL में होने चाहिए।

— ChssPly76

Answer 5

SQL कोड को "कोड" या "मेटाडेटा" माना जाना चाहिए?

कोड।

क्या संग्रहीत कार्यविधियाँ केवल प्रदर्शन अनुकूलन के लिए उपयोग की जानी चाहिए या वे डेटाबेस संरचना का एक वैध अमूर्त हैं?

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

ORM अपने अमूर्त होने के कारण खुद को अनुकूलन के लिए उधार नहीं देता है। IME, ORM का अर्थ है कि रेफ़रेन्शियल इंटिग्रिटी की कमी - डेटाबेस से रिपोर्ट करना मुश्किल बनाते हैं। क्या जटिलता में बचाया गया था, अब एक व्यावहारिक रूप से डेटा को बाहर निकालने में सक्षम हो गया है।

क्या प्रदर्शन एक महत्वपूर्ण कारक है? विक्रेता लॉक-इन के बारे में क्या?

नहीं, सरलता है। विक्रेता लॉकिन डेटाबेस के साथ भी होता है - एसक्यूएल अपेक्षाकृत मानकीकृत है, लेकिन चीजों को करने के विशिष्ट तरीके अभी भी विक्रेता हैं।

Comments

SQL कोड को कॉल करने के लिए +1। बहुत से ORM उपकरण SQL को छिपाने की कोशिश करते हैं, जब वास्तव में यह व्यक्त करने के लिए सबसे अच्छी भाषा होती है कि आप क्या करने की कोशिश कर रहे हैं। और मैं आपकी राय से सहमत हूं कि संग्रहीत प्रक्रियाएं ओआरएम से बेहतर हैं, हालांकि मुझे संदेह है कि यहां एक लोकप्रिय राय होगी।

— डैनियल प्राइडेन

Answer 6

जावा दुनिया में विक्रेता लॉक-इन का डर दिलचस्प है।

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

इसलिए, केवल विक्रेता एग्नॉस्टिक एसक्यूएल के सिद्धांत के आधार पर अपने एसक्यूएल कॉल को लागू करने के तरीके पर निर्णय न करें - ऐसा करने के लिए एक वास्तविक (व्यावसायिक) कारण है।

Comments

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

— एड्रियन

Answer 7

Stored Procedures के अंदर SQL को डेटाबेस सिस्टम द्वारा ऑप्टिमाइज़ किया जाता है और गति के लिए संकलित किया जाता है - यही इसका प्राकृतिक घर है। SQL को डेटाबेस सिस्टम द्वारा समझा जाता है, डेटाबेस सिस्टम द्वारा पार्स किया जाता है। यदि आप कर सकते हैं तो डेटाबेस में अपनी एसक्यूएल रखें; इसे संग्रहीत कार्यविधियों या फ़ंक्शंस या लॉजिक की जो भी यूनिट्स डेटाबेस सिस्टम प्रदान करता है, उसमें लपेटें, और आपके द्वारा या किसी अन्य उपकरण में से किसी एक उपकरण का उपयोग करके इसे सरल कॉल करें।

डेटाबेस के लिए SQL कोड को db के बाहर क्यों स्टोर करें? अक्सर विकास की गति के लिए। ORM मैपिंग का उपयोग क्यों करें? - कुछ लोग कहते हैं कि ORM मानचित्रण विभिन्न डेटाबेस प्रणालियों में अनुकूलता प्रदान करता है; हालाँकि शायद ही कभी वास्तविक दुनिया में कोई एप्लिकेशन कभी डेटाबेस प्लेटफ़ॉर्म से दूर जाता है, विशेष रूप से तब बनाया गया था जब वह प्रतिकृति जैसी उन्नत सुविधाओं का उपयोग करना शुरू कर देता है, और दुर्लभ अवसर के लिए ऐसा होता है कि डेटाबेस सिस्टम को स्वैप किया जाता है, कुछ काम वारंटेड होते हैं । मेरा मानना ​​है कि ORM की कमियों में से एक यह अक्सर SQL ज्ञान की कमी या db में कोड की देखभाल की कमी के लिए विकल्प है। इसके अलावा ORM देशी डेटाबेस के प्रदर्शन से मेल नहीं खाएगा, भले ही वह करीब आ जाए।

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

Comments

+1 अच्छा बिंदु। आप इस ब्लॉग पोस्ट में रुचि लेंगे, मुझे लगता है: डेटाबेस-programmer.blogspot.com/2010/12/… ।

— लुकास ईडर

Answer 8

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

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

• ORM - यह आपके द्वारा लिखी जाने वाली SQL की मात्रा में कटौती करता है और आपके लिए बहुत सारे विवरणों को संभालता है। आपको कुछ कस्टम SQL करने की आवश्यकता होगी। सुनिश्चित करें कि आपके पास एक ORM है जो इसे इनायत से संभालता है।
• डेटा एक्सेस ऑब्जेक्ट - डेटा एक्सेस करने वाली ऑब्जेक्ट में SQL रखें। यह आपके डेटाबेस को इनकैप्सुलेट करता है और इसे बनाता है ताकि आपके बाकी एप्लिकेशन को अंतर्निहित DB संरचना के बारे में जानने की जरूरत न पड़े, बस इन ऑब्जेक्ट्स के लिए इंटरफ़ेस।
• संग्रहीत कार्यविधियाँ - यह आपके सभी SQL को आपके डेटाबेस में रखता है और आपके DBA के लिए यह जानना आसान बनाता है कि क्या हो रहा है। आपको बस इतना करना है कि आपके कोड में स्टोर किए गए प्रॉपर कॉल हैं

Answer 9

हम आईबैटिस एसक्यूएल मैपर का उपयोग करने के लिए होते हैं, जो कि हाइबरनेट जैसे ओआरएम की तुलना में धातु के करीब है। IBatis में आप SQL स्टेटमेंट को रिसोर्स फाइल्स (XML) में डालते हैं, जिसे क्लासपाथ में होना चाहिए।

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

Answer 10

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

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

संग्रहीत procs SQL पाठ को DB में वापस रखते हैं और उन DEPLOYING और CUSTOMIZING (जो इसे समर्थन करने के लिए उचित डिजाइन की बहुत आवश्यकता होती है) द्वारा अपेक्षाकृत तत्काल परिवर्तन की अनुमति देते हैं।

सभी अनुमानों को विचारों के माध्यम से होना चाहिए और समान कारणों के लिए सरल चयन, सभी प्रक्षेपण तर्क को दृश्य के भीतर समाहित किया जाना चाहिए।

Comments

विचारों का उल्लेख करने के लिए +1। यह प्रश्न के सारांश में अभी तक परिलक्षित नहीं हुआ है

— लुकास ईडर

Answer 11

मेरा सुझाव है कि फैक्टरी लेआउट के साथ DAO का उपयोग करें। तो उदाहरण वस्तुओं आप की जरूरत होगी:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

यह शैली डेटा इंटरैक्शन को परत करती है, इसलिए आपको डेटाबेस को स्विच करने या ORM प्रौद्योगिकियों पर जाने के लिए केवल कोड की एक परत को बदलना होगा।

Answer 12

वास्तव में इन तीनों में कोई बहुत अंतर नहीं है:

1. व्यावसायिक वस्तुओं में हार्डकोड
2. SQLJ खंडों में एंबेडेड
3. डेटा एक्सेस ऑब्जेक्ट्स जैसे अलग-अलग कक्षाओं में इनकैप्सुलेट

मैं मान रहा हूँ कि आप SQL कोड को एक स्ट्रिंग रूप में सीधे अपने जावा कोड में एम्बेड करने जा रहे हैं। जबकि 1 और 3 संभवतः JDBC का सीधा उपयोग करेंगे (या Apache DbUtils जैसे कुछ उपकरण ), 2 स्टैक में प्रीप्रोसेसर तकनीक जोड़ता है, जो संकलन से पहले संबंधित JDBC कोड का निर्माण करता है।

तो, अनिवार्य रूप से, यदि इन समाधानों में एसक्यूएल एम्बेडिंग शामिल है, तो आप इनमें से किसी भी तकनीक का उपयोग कर सकते हैं:

• जेपीए मानदंड एपीआई , जेपीक्यूएल को जावा में आंतरिक डोमेन-विशिष्ट भाषा के रूप में मॉडलिंग करता है
• jOOQ , जावा में आंतरिक डोमेन-विशिष्ट भाषा के रूप में SQL मॉडलिंग

SQLJ के माध्यम से या वास्तविक स्ट्रिंग संघनन के माध्यम से अधिक प्रकार से जावा में SQL को एम्बेड करने में आपकी सहायता करने के लिए अन्य उपकरण भी हो सकते हैं।

Answer 13

किस अनुभव से, मेरे पास, डीएओ वस्तुओं में कठोर कोडिंग एसक्यूएल स्टेटमेंट है, जो व्यापक रूप से उपयोग किया जाता है, हालांकि, मुझे लगता है कि यह कम से कम पसंदीदा तरीका होना चाहिए। गुण फ़ाइल में sql कथनों को संग्रहीत करने के लिए सबसे अच्छा अभ्यास होना चाहिए। और java.util.Properties कहते हैं, गुण फ़ाइलों के लिए एक अंतरफलक के माध्यम से DAO वस्तु में बयान मिलता है । तैयार बयान दृष्टिकोण के माध्यम से एसक्यूएल के बयानों को 'पैरामीटर?' से जोड़ा जा सकता है ।

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

Comments

कुछ लोगों को आपत्ति हो सकती है कि यह SQL इंजेक्शन के जोखिम को पेश करेगा। उस बारे में आपकी क्या राय है?

— एड्रियन

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

— डैनियल प्राइडेन

हाय डैनियल, मेरा मतलब यह नहीं था, आप एसक्यूएल प्रॉक्स नहीं लिखते हैं, मेरा मतलब सिर्फ यह है कि आप संग्रहीत प्रोक्स को कॉल करते हैं, जिस तरह से, मैंने उल्लेख किया है। यह आपको एक बेहतर नियंत्रण रखने में मदद करता है, संग्रहीत पैरामीटर के पास, साथ ही साथ।

— मशीन

Answer 14

संसाधन बंडलों में मेरा अंत। मुझे पता है कि यह सामान्य नहीं है, लेकिन यह मेरे लिए और किसी को भी "मेरे अलावा" बनाए रखने के लिए सबसे आसान है। यह सीधा और तार्किक है।

मैं वास्तव में यह देखने के लिए उत्सुक हूं कि क्या कोई मेरे दृष्टिकोण का भी उपयोग करता है।

Comments

जिज्ञासु आप SQL को DB में क्यों नहीं रखते?

— 18 क्यू पर जे क्यू कतार

@Xepoch - तुम्हारा क्या मतलब है? बयान संसाधन बंडलों (प्रॉपर्टीज़ फ़ाइल्स) में होते हैं जो संस्थाओं के समान पैकेज में होते हैं, इसलिए customer.properties का संबंध Customer.class से होता है। डेटा DB में संग्रहीत किया जाता है।

— ब्रेट रायन

Answer 15

जैसा कि एक rexem ने लिखा कि SQL स्टैटिमेंट्स कोड हैं - उन्हें कोड की तरह माना जाना चाहिए, न कि एक्सटर्नाइज्ड (unles आपके पास अच्छा कारण) लेकिन कोड के साथ रखा गया जो SQL डेटा को / से उस स्टेटमेंट में प्रोसेस करता है। टॉड्स फ्रेमवर्क ORMs / iBatis दिन-प्रतिदिन JDBC विकास के लिए बहुत सारे सरलीकरण प्रदान करता है।

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

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

सरलतम समाधान (पी), बनाए रखने के लिए कठिन (सी)

* Embedded in SQLJ clauses

बेटर सिंटैक्स चेकिंग (P), ओडी डायनेमिक क्वेश्चन (C) की कमी, JDBC (C) की तुलना में कम परफ्यूमेंस, कोई इतना लोकप्रिय (C) नहीं

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

यह विशिष्ट मामला होना चाहिए जो आपको करना चाहिए (सी) या यदि आपका मतलब ओआरएम (पी) है;

* External files (e.g. Properties or Resource files)

Mantain (P) के लिए आसान है, लेकिन त्रुटियों की जांच करना कठिन है (C)

* Stored Procedures

उच्च secuirty (पी), कोड एक विक्रेता ताला मुश्किल समस्याओं में (सी) mantain करने के लिए (सी)