10 संभावित SQL त्रुटियाँ जो प्रोग्रामर बनाते हैं

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



जावा प्रोग्रामर वस्तु-उन्मुख और अनिवार्य सोच के साथ हस्तक्षेप करते हैं, जो उनके स्तर पर निर्भर करता है:
- महारत (कोई भी अनिवार्य रूप से कार्यक्रम कर सकता है)
हठधर्मिता (कहीं भी टेम्पलेट लगाने और उन्हें नाम देने का एक खाका)
- मनोदशा (एक वास्तविक वस्तु दृष्टिकोण लागू करना थोड़ा अधिक कठिन है)

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

जावा डेवलपर्स द्वारा JDBC या jOOQ में SQL का उपयोग करके (एक विशिष्ट आदेश के बिना) सामान्य गलतियाँ दी गई हैं। अन्य 10 त्रुटियों के लिए, इस लेख को देखें ।

1. NULL के बारे में भूल गए

गलतफहमी NULL शायद सबसे बड़ी गलती है जावा डेवलपर्स जब वे SQL लिख सकते हैं। ऐसा इसलिए हो सकता है क्योंकि NULL को UNKNOWN भी कहा जाता है। यदि इसे केवल UNKNOWN कहा जाता था, तो इसे समझना आसान होगा। एक और कारण यह है कि जब आप डेटा पुनर्प्राप्त करते हैं और चर को बांधते हैं, तो JDBC जावा नल में SQL NULL को दर्शाता है। यह Null = NULL (SQL) को null == null (JAVA) के समान व्यवहार करने का कारण बन सकता है।

NULL गलत धारणा के सबसे स्पष्ट उदाहरणों में से एक है जब NULL प्रेडिकेट्स का उपयोग स्ट्रिंग मान अभिव्यक्ति के साथ किया जाता है ।

एक और, अधिक विशिष्ट समस्या तब होती है जब नॉट-एन-जॉइन में एनएएलई मूल्य की समझ नहीं होती है।

दवा:
खुद को प्रशिक्षित करें। कुछ भी जटिल नहीं - SQL लिखते समय हमेशा NULL के बारे में सोचें:
- क्या NULL के संबंध में यह सही है?
- क्या NULL इस फ़ंक्शन के परिणाम को प्रभावित करता है?

2. जावा मेमोरी में डाटा प्रोसेसिंग

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

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

दवा:
हर बार जब आप जावा का उपयोग करके डेटा-उन्मुख एल्गोरिदम लिखते हैं, तो अपने आप से पूछें: "क्या इस काम को डेटाबेस में स्थानांतरित करना संभव है?"

3. UNION ALL के बजाय UNION का उपयोग करना

इस तथ्य पर शर्म आती है कि UNION ALL को UNION पर एक अतिरिक्त शब्द की आवश्यकता है। यह बहुत बेहतर होगा यदि SQL मानक समर्थन के लिए परिभाषित किया गया है:
- यूनिअन (दोहराव की अनुमति देता है)
- यूनिअन DISTINCT (नकल हटाता है)

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

याद रखें कि भले ही SQL मानक INTERSECT ALL और EXCEPT ALL को परिभाषित करता हो, न कि हर डेटाबेस इन छोटे-छोटे उपयोग के कार्यों को लागू कर सकता है।

दवा:
इस बारे में सोचें कि क्या आप हर बार UNION लिखना चाहते हैं।

4. एक बड़े नमूने को जगाने के लिए JDBC का उपयोग करना

अधिकांश डेटाबेस लिमिट ... OFFSET, TOP ... START AT, OFFSET ... FETCH ऑपरेटरों के माध्यम से किसी प्रकार के पृष्ठांकन का समर्थन करते हैं। इन कथनों के समर्थन के अभाव में, अभी भी डाउनलोड (Oracle) या ROW_NUMBER () OVER () फ़िल्टरिंग (DB2, SQL Server 2008, और अन्य) होने की संभावना है, जो मेमोरी में विभाजन से बहुत तेज़ हैं। यह मुख्य रूप से बड़े विस्थापनों पर लागू होता है!

दवा:
बस इन ऑपरेटरों, या एक उपकरण (जैसे jOOQ) का उपयोग करें जो आपके लिए इन ऑपरेटरों की नकल कर सकते हैं।

5. जावा मेमोरी में डेटा कनेक्शन

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

दवा:
यदि आप विभिन्न चरणों में विभिन्न तालिकाओं से चुनते हैं, तो फिर से सोचें, अचानक आप अपने अनुरोधों को व्यक्त कर सकते हैं।

6. यादृच्छिक कार्टेशियन उत्पाद से डुप्लिकेट को हटाने के लिए DISTINCT या UNION का उपयोग करना

जटिल जॉइन (JOIN) के कारण, कोई भी डेवलपर सार्थक SQL क्वेरी संबंधों का ट्रैक खो सकता है। अधिक विशेष रूप से, जब यौगिक विदेशी कुंजियों के साथ संबंधों का उपयोग करते हैं, तो आप JOIN ... बयानों पर सार्थक विधेयकों को जोड़ना भूल सकते हैं। इससे डुप्लिकेट स्ट्रिंग्स हमेशा या केवल असाधारण स्थितियों में हो सकती हैं। फिर कुछ डेवलपर्स डेटा दोहराव को रोकने के लिए एक DISTINCT स्टेटमेंट जोड़ सकते हैं। यह तीन कारणों से सही नहीं है:
"यह परिणामों को ठीक कर सकता है, लेकिन इसका कारण नहीं है।" और फिर भी यह सीमाओं की शर्तों के तहत परिणामों को हल नहीं कर सकता है।
- यह बड़े नमूनों के लिए धीमा है। दोहराव को हटाने के लिए DISTINCT एक ORDER BY ऑपरेशन करता है।
- यह बड़े कार्टेसियन कार्यों के लिए धीमा है जो अभी भी मेमोरी में लोड किए जाएंगे।

दवा:
आम तौर पर, यदि आप अवांछित डुप्लिकेट प्राप्त करते हैं, तो अपने JOIN विधेय को संशोधित करें। शायद वहाँ कहीं एक छोटे कार्टेसियन उत्पाद का गठन किया।

7. MERGE कथन का परिहार

यह वास्तव में गलती नहीं है, लेकिन शायद यह ज्ञान की कमी या शक्तिशाली MERGE ऑपरेटर की आशंका है। कुछ डेटाबेस UPSERT स्टेटमेंट के अन्य रूपों को जानते हैं, उदाहरण के लिए, MySQL ON DUPLICATE KEY UPDATE। वास्तव में, MERGE बहुत शक्तिशाली है, विशेष रूप से डेटाबेस में जो SQL सर्वर जैसे SQL सर्वर का विस्तार करते हैं।

दवा:
यदि आप INSERT और UPDATE या SELECT ... UPDATE और INSERT / UPDATE की श्रृंखला बनाकर UPSERT कर रहे हैं, तो फिर से सोचें। संसाधनों की दौड़ को जोखिम में डालने के बजाय, आप एक सरल MERGE अनुरोध लिख सकते हैं।

8. खिड़की के कार्यों के बजाय समग्र कार्यों का उपयोग करना

विंडो फ़ंक्शन के आगमन से पहले, एसक्यूएल में डेटा एकत्र करने का एकमात्र तरीका एक प्रक्षेपण में समग्र कार्यों के साथ-साथ ग्रुप बीई का उपयोग करना था। यह ज्यादातर मामलों में अच्छी तरह से काम करता है, और अगर एकत्रित डेटा को नियमित डेटा से भरा जाना चाहिए, तो एक समूहित क्वेरी को एक संलग्न क्वेरी में लिखा जा सकता है।
लेकिन SQL: 2003 विंडो फ़ंक्शन को परिभाषित करता है जो कई डेटाबेस प्रदाताओं द्वारा कार्यान्वित किया जाता है। विंडो फ़ंक्शंस ungrouped नमूनों पर डेटा एकत्र कर सकते हैं। वास्तव में, प्रत्येक विंडो फ़ंक्शन अपने स्वयं के स्वतंत्र विभाजन बाय ऑपरेशन का समर्थन करता है, जो रिपोर्ट बनाने के लिए एक महान उपकरण है।

विंडो कार्यों का उपयोग करने की अनुमति देगा:
- अधिक पठनीय एसक्यूएल का निर्माण करें (उप प्रश्नों में अभिव्यक्ति द्वारा कम हाइलाइट किए गए ग्रुप)
- प्रदर्शन में सुधार RDBMS अधिक आसानी से विंडो फ़ंक्शंस का अनुकूलन कर सकते हैं

दवा:
जब आप एक उप-क्वेरी में एक ग्रुप बाय अभिव्यक्ति लिखते हैं, तो इस बारे में सोचें कि क्या इसे विंडो फ़ंक्शन द्वारा व्यक्त किया जा सकता है?

9. विभिन्न मापदंडों के साथ स्मृति में छंटाई का उपयोग करना

ORDER BY ऑपरेटर CASE सहित कई प्रकार के भावों का समर्थन करता है, जो एक प्रकार के पैरामीटर को परिभाषित करते समय बहुत उपयोगी हो सकते हैं। आपको जावा मेमोरी में डेटा को केवल इसलिए छाँटना नहीं चाहिए:
- SQL सॉर्टिंग बहुत धीमी है।
- SQL सॉर्टिंग ऐसा नहीं कर सकती।

दवा:
यदि आप जावा मेमोरी में कोई SQL डेटा सॉर्ट कर रहे हैं, तो इस बारे में सोचें कि क्या इस सॉर्टिंग को डेटाबेस में ट्रांसफर करना संभव है? यह डेटाबेस में पृष्ठांकन के साथ अच्छी तरह से चला जाता है।

10. एक बार में कई रिकॉर्ड डालें

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

दवा:
हमेशा बड़े डेटासेट के बैच सम्मिलन का उपयोग करें।

विषय पर कुछ रोचक पुस्तकें

- बिल एंटविन द्वारा एसक्यूएल एंटीपार्टर्न
- मार्कस Winand द्वारा समझाया एसक्यूएल प्रदर्शन