Oracle में अशक्त संख्या का उपयोग नहीं करने का कारण?

Question

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

--- संपादित करें

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

Comments

आपका मतलब है, "उनके एपीआई निर्दिष्ट करता है" के अलावा अन्य?

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

हां, मैं इस बारे में अधिक उत्सुक हूं कि उनका एपीआई पहले स्थान पर क्यों निर्दिष्ट करेगा; क्या इस प्रथा का कोई कारण है, या यह सिर्फ कुछ हंसी है?

उच्चतम क्रम की निर्मलता!

— फिलु

SO पर संबंधित प्रश्न: लापता डेटा का प्रतिनिधित्व करने के लिए NULL के बजाय 'Z' का मानक उपयोग?

— एंड्री एम

Answer 1

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

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

यदि आप एक डेटाबेस स्कीमा ऐसा डिज़ाइन करने जा NULLरहे हैं, जिसमें किसी भी मान की अनुमति नहीं है, तो इससे कोई मतलब नहीं है कि अकेले जाने के लिए जादू के मूल्यों की आवश्यकता होती है ताकि यह इंगित किया जा सके कि कुछ अज्ञात है। यह उन सभी समस्याओं का परिचय देता है, जिसमें NULLमानों की अनुमति होती है, साथ ही यह उन जादुई मूल्यों की जांच करने के लिए अतिरिक्त कोड जोड़ता है, जिन्हें सभी जगह दोहराया जाना है। यह एक एपीआई को विकसित करने के लिए कोई मतलब नहीं है जो डेटाबेस डिज़ाइन की परवाह किए बिना जादू के मूल्यों को पारित करने की आवश्यकता है - यदि आप जादू के मूल्यों के लिए चेक के साथ अपने कोड को हॉबी करने जा रहे हैं, तो आपको वास्तव में ऐसा नहीं करना चाहिए कि पागलपन अन्य प्रणालियों के लिए प्रचारित न करें ।

Comments

मैजिक मानों की जांच के लिए +1 और अतिरिक्त कोड अच्छी तरह से ज्ञात कार्यों का उपयोग नहीं कर सकते हैं COALESCE()- इसलिए यह और भी जटिल हो जाता है।

— ypercube y

और मानों को उस स्तंभ पर किसी भी सूचकांक में संग्रहीत करने की आवश्यकता है। इंडेक्स को शून्य मानों को संग्रहीत करने की आवश्यकता नहीं है।

— ट्रिप काइनेटिक्स

Answer 2

NULL के बजाय मैजिक वैल्यू का उपयोग करने के लिए कोई Valid Reason नहीं है। हो सकता है कि यह गड़बड़ी पैदा करने वाले व्यक्ति की विचार प्रक्रिया हो। वे कुछ इस तरह लिखते हैं:

 SELECT c1, c2 FROM t1 WHERE c3 < 30;

जब यह उन परिणामों को वापस नहीं करता है जिनकी वे अपेक्षा कर रहे हैं, तो उन्हें पता चलता है कि इसमें NULLs शामिल नहीं है और इसे लिखने की आवश्यकता होगी:

SELECT c1, c2 FROM t1 WHERE c3 < 30 OR c3 IS NULL;

वे भविष्य में इसे लिखना या भूलना नहीं चाहते हैं, इसलिए वे सभी NULLS -5000 बनाने के समाधान के साथ आते हैं। जादुई रूप से उनकी मूल क्वेरी NULL को बिना किसी बदलाव के संभालती है। उन्हें इस बात का एहसास नहीं है कि अब जो कोई इन मूल्यों को छोड़ना चाहता है, उसे यह लिखना होगा:

SELECT c1, c2 FROM t1 WHERE c3 < 30 AND c3 <> -5000;

या अगर वे इन मूल्यों को चाहते थे और एक उच्च श्रेणी की खोज कर रहे हैं:

SELECT c1, c2 FROM t1 WHERE c3 > 40 OR c3 = -5000;

वे यह भी महसूस नहीं कर सकते हैं कि निम्नलिखित अब सार्थक नहीं होगा:

SELECT c1, c2 FROM t1 WHERE c3 IS NULL;

इसके बजाय एक व्यक्ति को जादू का मूल्य याद रखना होगा। प्रत्येक डेटाटाइप का उपयोग करने के साथ उन्हें 1/1 // 1900, "Z", -5000 जैसे अधिक जादुई मूल्यों को याद रखना होगा। इसके अलावा, जब डेटा में जादू का मूल्य होता है, तो उन्हें वैकल्पिक जादू मूल्यों को भी याद रखना चाहिए।

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

Answer 3

यह बिलकुल पागलपन है और इसका कोई औचित्य नहीं है। NULLएक मूल्य के अभाव का प्रतिनिधित्व करने के लिए बनाया गया था और -5000 जैसे वास्तविक मूल्य का उपयोग करने के लिए बोनर्स है।

आमतौर पर मैं इस जवाब को छोटा नहीं लिखूंगा, लेकिन यह सवाल dba.se पर सबसे अधिक दिखाई देने वाला है और अधिक बेहतर उत्तर देता है।

Answer 4

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

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

अधिकांश मुद्दे जो अशक्त होते हैं, एक बार समझ में आने पर (बेहतर सामान्यीकरण, फ़ंक्शन आधारित या बिटमैप इंडेक्स के साथ या एक साधारण WHERE x IS NULL नहीं) से निपटा जा सकता है। क्या आपको लगता है कि कुछ बड़े टेल्को में या अमेज़ॅन पर मासिक प्रदर्शन बैठक में कुछ डीबीए अपने विशाल डेटासेट पर प्रश्नों को तेज करने के लिए इस महान योजना की रूपरेखा तैयार कर रहे हैं "मनमाने ढंग से मान के साथ अशक्त की जगह, जैसे कुछ -5000, या जो भी हो - मैं मूल्य पर खुला हूँ ... "। या क्या आपको लगता है कि वे अवांछित डेटा और फ़िल्टर ऑप्टिमाइज़ेशन को फ़िल्टर करने के लिए बेहतर एप्लीकेशन डिज़ाइन के बीच अपना समय बिताते हैं जो उन्हें दिए गए वास्तविक डेटा के आधार पर होता है ? ठीक है, ठीक है, शायद एक मासिक बैठक थोड़ी आशावादी है, लेकिन जब भी वे होते हैं मैं आपके आश्वासन दे सकता हूं कि "बेहतर एपीआई के लिए -5000 (या जो भी हो) के साथ नल को बदलना एक एजेंडा आइटम नहीं है।"

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

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

तो आप उन नल से बचें जो आप आवेदन स्तर पर नहीं चाहते हैं और उनके साथ आप डेटाबेस में व्यवहार करते हैं जहां आप उन्हें स्वीकार करते हैं अन्यथा जिराफ़ + जिराफ़ = हिप्पो के रूप में अपने व्यर्थ डेटा की कमी आपको परेशानी में डाल देगी।

Comments

मेरे माता-पिता आलसी नहीं थे और वैसे भी मेरा कोई बीच का नाम नहीं है। सभी लोग यूएसए में नहीं रहते हैं।

— ypercube y

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

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

— ypercube y

यदि मेरा मध्य नाम "-5000" था, तो मुझे अच्छा लगेगा! : डी

— फिलो