नल का एक उपनाम कई डेटाबेस में समस्याओं का कारण कैसे बनता है?

Question

मैंने बीबीसी पर एक लेख पढ़ा । उनके द्वारा कहे गए उदाहरणों में से एक यह था कि उपनाम 'नल' वाले लोगों को कुछ वेबसाइटों में अपना विवरण दर्ज करने में समस्या हो रही है।

उनके द्वारा की जा रही त्रुटि के बारे में कोई स्पष्टीकरण नहीं दिया गया है।

लेकिन जहां तक ​​मुझे पता है कि स्ट्रिंग 'नल' और वास्तविक नल का मूल्य पूरी तरह से अलग है (एक डेटाबेस बिंदु से)।

यह एक डेटाबेस में समस्याएं क्यों पैदा करेगा?

Comments

यह कुछ हद तक प्रसिद्ध ब्लॉग लेख है, जो प्रोग्रामर नामों के बारे में बनाते हैं, जो उस बीबीसी के लेख में उद्धृत लोगों में से एक द्वारा लिखे गए हैं: kalzumeus.com/2010/06/17/…

— Jörg W Mittag

प्रासंगिक xkcd

— डेविड ग्रिनबर्ग

यह भी देखें: stackoverflow.com/questions/4456438/...

— टेलीफोन

पहली बार मैंने इस आदमी को टीवी पर देखा मैंने मान लिया कि यह एक डेटाबेस बग था। तब मुझे पता चला कि यह वास्तव में उसका नाम है।

— नैट एल्ड्रेडगे

@JarrodRoberson आप "जेनिफर नल" द्वारा सामना किए गए मुद्दों का विवरण और ओपी द्वारा पोस्ट किए गए लिंक में समान नाम का विवरण कैसे दे सकते हैं? यह एक वास्तविक मुद्दा है जो वास्तविक अंत उपयोगकर्ताओं का सामना करता है।

— स्टीवन बर्नैप

Answer 1

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

इसका उपाय NOT NULLडेटाबेस में गैर-शून्य कॉलम घोषित करना है, और डेटाबेस रिकॉर्ड में स्ट्रिंग संचालन लागू नहीं करना है। अधिकांश भाषाओं में उत्कृष्ट डेटाबेस एपीआई होते हैं जो स्ट्रिंग-स्तरीय इंटरफेस को अनावश्यक बनाते हैं। उन्हें हमेशा पसंद किया जाना चाहिए, चूंकि वे अन्य गलतियां भी करते हैं जैसे कि एसक्यूएल इंजेक्शन कम संभावना है।

Comments

इस मामले में, हालांकि, यदि आप प्रश्न में लेख पढ़ते हैं, तो अंतिम नाम फ़ील्ड बनाने से NOT NULLअन्य लोगों के लिए समस्याओं का एक पूरा सेट हो जाएगा। "कुछ व्यक्तियों का केवल एक ही नाम होता है, न कि किसी का नाम और उपनाम।"

— माइकइलियार

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

— माइकइलियार

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

— जिम्मीजाम्स

@JimmyJames हाँ, ज़िप कोड संख्यानुसार संग्रहीत होते हैं और अचानक किसी के भी यहाँ रहने का आधार -8 ज़िप कोड होता है। "यदि आप इसके साथ गणित नहीं कर रहे हैं, तो यह एक स्ट्रिंग है, पूर्ण विराम।"

— मीकलियर

@mikeTheLiar। नामों को एकल स्ट्रिंग के रूप में मानने में समस्या (आमतौर पर बेहतर, मैं सहमत हूं) है जब उपनाम से वर्णानुक्रमिक छंटाई की आवश्यकता होती है।

— TRIG

Answer 2

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

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

Comments

यह असुरक्षित स्ट्रिंग प्रक्षेप के प्रकार के कारण होने की कल्पना करना मुश्किल है जो SQL इंजेक्शन का कारण बन सकता है। आप एक SQL क्वेरी में उपयोगकर्ता इनपुट उद्धृत करने के लिए भूल जाते हैं (उदाहरण के लिए INSERT INTO users (first, last) VALUES($first, $last)मूल्यांकन करता है करने के लिए INSERT INTO users (first, last) VALUES(Jennifer, Null)) हर किसी को जिनके नाम हैं नहीं वैध एसक्यूएल कीवर्ड या स्तंभ नाम सिर्फ जा रहे हैं त्रुटियों फेंक और उनके रिकॉर्ड या तो नहीं डाला गया। कारण अधिक जटिल होना चाहिए।

— एंड्रयू मेडिको

@AndrewMedico अपने पुआल आदमी उदाहरण में हाँ, लेकिन वहाँ बहुत से तरीके गलत करने के लिए कर रहे हैं। कभी भी <स्ट्राइक> मूर्खता </ स्ट्राइक> अज्ञान की शक्ति को कम मत समझो। लब्बोलुआब यह है कि हमें पता नहीं है कि वास्तविक समस्या क्या है क्योंकि हम प्रश्न में कोड की समीक्षा नहीं कर सकते हैं

— एरिक

Answer 3

ठीक है, डेटाबेस में प्रवेश करने से पहले, यह एक DOM तत्व है, फिर एक जावास्क्रिप्ट चर चारों ओर से गुजरता है, मान्य होता है, और हेरफेर किया जाता है, फिर एक JSON मान, फिर एक चर जो बैकेंड JSON लाइब्रेरी में आप उपयोग कर रहे हैं, फिर एक चर चारों ओर से गुजरता है, आपकी बैकएंड प्रोग्रामिंग लैंग्वेज में वैरिफाइड और हेरफेर, फिर किसी प्रकार का DAO का तत्व, फिर SQL स्ट्रिंग का हिस्सा। फिर मूल्य वापस पाने के लिए, आप इसे उल्टा करते हैं। प्रोग्रामर के लिए गलतियाँ करने के लिए बहुत सी जगह है, और आमतौर पर बहुत कुछ यह स्थिर टाइपिंग के लाभ के बिना।

Answer 4

सबसे अधिक संभावना है कि यह एक प्रोग्रामिंग मुद्दा है। यदि आप इस उत्तर को यहाँ देखते हैं कि कैसे NULLs पास हो रहे हैं तो आप आसानी से कुछ अवांछित व्यवहार का कारण बन सकते हैं यदि आप "Mr. Null" थे।

https://stackoverflow.com/questions/4620391/mysql-and-php-insert-null-rather-than-empty-string

आप देख सकते हैं कि अगर कुछ डेटा एलिमेंट को NULL के रूप में पास किया गया तो डेटा को डेटाबेस में डेटाबेस null के रूप में इंटरपोल किया जाएगा।

"NULL"! = डेटाबेस नल

कुछ मामलों और संबंधित व्यवहार का उपयोग करें ...

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

एक अन्य मामला यह है कि अंतिम नाम डेटाबेस में अशक्त था। मि। NULL डाला जाता है और DBNull.Value में बदल जाता है जो "NULL" जैसा नहीं है। डालने के बाद हम श्री नल को नहीं ढूंढ सकते क्योंकि उनका अंतिम नाम "NULL" नहीं है, लेकिन वास्तव में एक डेटाबेस शून्य मान है।

तो, उन समस्याओं के 2 मामलों होगा। जैसा कि @Amon बताते हैं, डेटाबेस में स्वयं nulls के साथ कोई समस्या नहीं है, हालांकि किसी को समझना चाहिए कि प्रत्येक RDMS उदाहरण में नल कैसे संभाले जाते हैं क्योंकि विभिन्न विक्रेताओं के बीच मतभेद होंगे।

Comments

"आप देख सकते हैं कि अगर कुछ डेटा एलिमेंट को NULL के रूप में पास किया गया तो डेटा को डेटाबेस में डेटाबेस null के रूप में इंटरपोल किया जाएगा।" - जुड़ा हुआ SO प्रश्न / स्वीकृत-उत्तर यह दिखाने के लिए प्रकट नहीं होता है?

— MrWhite

Answer 5

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

यह इस तथ्य से जटिल है कि अन्य प्रकार के डेटा; उदाहरण के लिए संख्याओं को या तो रूप में स्वीकार किया जाता है क्योंकि व्याख्या अस्पष्ट है।

Comments

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

— अंडरस्कोर_ड

Answer 6

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

1. कुछ का कोई ज्ञात मूल्य नहीं है
2. किसी चीज का कोई मूल्य नहीं है

हालांकि संदर्भ कभी-कभी उन अवधारणाओं के बीच अंतर करने के लिए पर्याप्त हो सकता है, ऐसे समय होते हैं जब यह वास्तव में नहीं होता है। यदि कोई खोज क्वेरी रखने के लिए रिकॉर्ड का उपयोग कर रहा है, उदाहरण के लिए, यह कहने में कोई अंतर नहीं होना चाहिए कि "मैं किसी के नाम से चाहता हूं [जो भी हो] जिसका कोई अंतिम नाम नहीं है", बनाम "मुझे ऐसा कोई चाहिए जिसका पहला नाम है" जो भी हो] लेकिन जिसका अंतिम नाम अज्ञात है। " कई डेटाबेस इंजनों में एक या दूसरे अर्थ के प्रति पूर्वाग्रह होता है, लेकिन वे सभी समान नहीं होते हैं। कोड जो एक डेटाबेस इंजन से एक तरह से काम करने की उम्मीद कर रहा है, अगर वह अलग इंजन पर चलता है जो अलग-अलग तरीके से चलता है।

Comments

यदि किसी स्ट्रिंग का कोई मान नहीं है, तो मान रिक्त स्ट्रिंग होना चाहिए, न कि स्ट्रिंग।

— बायरन जोन्स

Answer 7

मौजूदा उत्तरों में से अधिकांश किसी एप्लिकेशन के गैर-SQL भागों पर ध्यान केंद्रित करते हैं, लेकिन SQL में एक समस्या भी हो सकती है:

यदि उन रिकॉर्ड्स को फ़िल्टर करने का निर्देश दिया गया है जहां उपयोगकर्ता का अंतिम नाम उपलब्ध नहीं है, तो कोई व्यक्ति जो SQL को बहुत अच्छी तरह से नहीं समझता है, वह फ़िल्टर लिख सकता है WHERE u.lastname != 'NULL'। SQL काम करने के तरीके के कारण, यह जांचने के लिए दिखाई देगा कि क्या u.lastname IS NOT NULL: सभी NULLरिकॉर्ड फ़िल्टर किए गए हैं। सभी गैर NULLरिकॉर्ड बने हुए हैं।

जहां रिकॉर्ड्स के लिए पाठ्यक्रम को छोड़कर u.lastname == 'NULL', लेकिन परीक्षण के दौरान ऐसा कोई रिकॉर्ड उपलब्ध नहीं हो सकता है।

एसक्यूएल किसी प्रकार के फ्रेमवर्क द्वारा उत्पन्न होने पर यह अधिक संभव हो जाता है, जहां वह फ्रेम NULLपैरामीटर के साथ गैर- अच्छाता के लिए जांच करने के लिए आसानी से सुलभ तरीके को उजागर नहीं करता है , और कोई नोटिस "अरे, अगर मैं स्ट्रिंग में गुजरता हूं, तो NULLयह ठीक वैसा ही जैसा मैं चाहता हूं! "