नकारात्मक कुंजियों का उपयोग किस लिए किया जाता है?

Question

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

तालिका को अनुक्रमित करते समय नकारात्मक (या हस्ताक्षरित) कुंजियों का होना कब और क्यों उपयोगी है?

Comments

सबसे पहले, जो कोई भी प्रतिक्रिया छोड़ने के बिना downvoting है, आप एक सेवा कर रहे हैं। अगला, इस उत्कृष्ट प्रश्न का उत्तर।

— jcolebrand

यह विषय पेचीदा है। मैंने व्यक्तिगत रूप से इस अवधारणा के बारे में कभी नहीं सुना है। इस सवाल को कभी कम नहीं किया जाना चाहिए था। इस अवधारणा को शुरू करने के लिए मेरी ओर से +1।

— रोलैंडमाइसीडीडीबीए

Answer 1

सभी प्राथमिक कुंजी एक मूल्य है जिसे हमने निर्धारित किया है वह मूल्य है जो एक रिकॉर्ड में अत्यंत महत्व का है। चाहे वह कुंजी एक हस्ताक्षरित int, एक अहस्ताक्षरित int, एक स्ट्रिंग, एक बूँद (वास्तव में, सीमाएं हैं) या एक UUID (या जो भी नाम आज लेता है), तथ्य अभी भी खड़ा है कि यह एक कुंजी है, और यह है कि अत्यंत महत्व की बात।

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

जैसे कि टेबल में "नेगेटिव कीज" होना मददगार होगा, वैसे ही यह सवाल है कि "टेबल में कीज़ रखना उपयोगी क्यों है"। एक कुंजी के "मूल्य" का एक कुंजी के रूप में इसकी स्थिति पर कोई प्रभाव नहीं पड़ता है। एक कुंजी एक कुंजी है एक कुंजी है।

यदि कुंजी वैध है तो क्या महत्वपूर्ण है।

जैसा कि यह महत्वपूर्ण है कि कुंजी नकारात्मक होने की अनुमति देने के लिए उपयोगी होगा, मैं कुछ कारणों का सुझाव दे सकता हूं:

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

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

मैं आगे बढ़ सकता था, लेकिन वास्तव में एकमात्र कारण है कि संख्या का नकारात्मक होना महत्वपूर्ण है अगर आप या मैं इसे महत्व देते हैं। इसके अलावा, कुंजी के मूल्य का कोई बड़ा कारण नहीं है कि कुंजी पर कोई असर पड़े।

Comments

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

— गेरेट क्लैबोर्न

@Garet ~ तो आप एक अच्छा बिंदु बनाते हैं: "कुंजी का मान किसी तरह कोडिंग में उपयोगी था" और मैं समय-समय पर अपनी कुंजियों का उपयोग उस तरीके से करता हूं, लेकिन इसका डेटाबेस पहलू से कोई लेना- देना नहीं है। डेटाबेस एक स्टोरहाउस है। दूसरी ओर, डेटा की खपत करने वाला एप्लिकेशन मूल्यों की परवाह करता है । लेकिन हाँ, यह +/- बूलियन एक साफ-सुथरी चाल है, मैंने देखा है कि यह इस तरह के एक प्रभाव के लिए कई बार इस्तेमाल किया है।

— jcolebrand

-1 कि इस तरह के दोहरे उद्देश्य मूल्यों को लागू करने के लिए एक बुरा विचार के अलावा कुछ भी नहीं है। आपको एक इंट और एक बूल की आवश्यकता है? एक इंट और एक बूल का उपयोग करें।

— जैक कहते हैं कि topanswers.xyz

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

— jcolebrand

@JackPDouglas ~ मैंने उस विशेष उदाहरण का उपयोग किया क्योंकि एक बहुत अच्छी तरह से ज्ञात साइट (साइटों का नेटवर्क) है जिसके बारे में आपने सुना होगा कि वह बहुत काम करता है, इसलिए मैं इसे खारिज नहीं करना चाहता, क्योंकि यह एक वैध है "छल"। इस उपयोगकर्ता को देखें dba.stackexchange.com/users/-1/community और मुझे बताएं कि उसकी आईडी क्या है। मैं आपको लगभग आश्वस्त कर सकता हूं कि उपयोगकर्ता प्राथमिक (और कई अन्य तालिकाओं में एक विदेशी) कुंजी है। सिर्फ इसलिए कि यह आपके लिए खराब एप्लिकेशन डिज़ाइन है, इसका मतलब यह नहीं है कि यह मान्य नहीं है। लेकिन एक बार फिर, यह डीबी डिजाइन नहीं है, यह डोमेन डिजाइन है। दी, डाटाबेस तर्क का समर्थन करता है यह

— jcolebrand

Answer 2

यदि हम पहचान या ऑटोनम्बर कॉलम के बारे में हैं, तो मान का कोई अर्थ नहीं होना चाहिए। (कभी-कभी ऐसा होता है, एसओ के चैट उपयोगकर्ताओं के अनुसार, जिसे मैंने खुद से पहले किया है

हालाँकि, यदि आप हस्ताक्षर किए गए पूर्णांक का उपयोग कर रहे हैं, तो आमतौर पर आप अपनी सीमा का आधा हिस्सा खो देंगे।
देखें: क्या करना है जब एक तालिका में एक क्षेत्र अधिकतम हस्ताक्षरित या अहस्ताक्षरित 32 बिट पूर्णांक तक पहुंचता है?

एक और उदाहरण: छोटे प्रतिकृति परिदृश्यों में, एक साइट के लिए नकारात्मक मूल्यों का उपयोग करना और दूसरे के लिए सकारात्मक किसी भी पंक्ति के स्रोत का कुछ अंतर्निहित ज्ञान देता है।

Comments

और सुनिश्चित करें कि आप किसी तरह से प्रत्येक साइट पर मान इनपुट में बाधा डाल रहे हैं अन्यथा आप एक भयानक गड़बड़ में समाप्त हो जाएंगे जब आपका "अंतर्निहित ज्ञान" गलत हो जाएगा।

— जैक का कहना है कि topanswers.xyz

@JackPDouglas: गलत साइट पर मान उत्पन्न करने से बचने के लिए आप REPLICATION के लिए उपयोग नहीं करेंगे

— gbn

चेक की कमी के साथ ? इसके अलावा, क्या NOT FOR REPLICATIONआप जानते हैं कि एक MySQL (या अन्य) एनालॉग है?

— जैक का कहना है कि topanswers.xyz

@JackPDouglas: क्षमा करें, गैर SQL सर्वर के बारे में निश्चित नहीं

— gbn

Answer 3

सभी डेटाबेस सिस्टम अहस्ताक्षरित पूर्णांक प्रकारों का समर्थन नहीं करते हैं, MSSQL उन में से एक है जो नहीं करता है। इन मामलों में पूर्णांक कुंजी फ़ील्ड में नकारात्मक मान संभव हैं, क्योंकि वे इस प्रकार में संभव हैं (आप उन्हें ब्लॉक करने के लिए नियमों या ट्रिगर्स का उपयोग कर सकते हैं, जैसा कि इस उदाहरण में दिखाया गया है , लेकिन संभवतः ऐसे नियमों को लागू करने के ओवरहेड को जोड़ने की आवश्यकता नहीं है हर ब्लॉक / अद्यतन)।

जहां तक ​​डेटाबेस का संबंध है, एक प्राथमिक कुंजी का वास्तविक मूल्य तब तक मायने नहीं रखता है जब तक यह तालिका के भीतर अद्वितीय है। इसके लिए -42 और 42 एक ही तरह से दो अलग-अलग संख्याएँ हैं 42 और 69 हैं - अर्थ केवल नकारात्मकता पर लगाया जाएगा या आपके कोड द्वारा मूल्य का नहीं।

अहस्ताक्षरित पूर्णांक प्रकारों का समर्थन नहीं करना संभवतः जटिलता को कम करने के आधार पर एक डिजाइन निर्णय है - अर्थात उन दोनों के बीच मान निर्दिष्ट करते समय श्रेणियों की जाँच के बारे में चिंता करने के लिए दो अलग-अलग 32 बिट पूर्णांक प्रकार नहीं चाहते हैं। यह एक 0 या 1 से शुरू होने वाले ऑटो वेतन वृद्धि क्षेत्र में संभव इंडेक्स की संख्या को सीमित करता है जो एक अहस्ताक्षरित प्रकार में संभव होगा (~ 4e9 के बजाय ~ 2e9) लेकिन यह शायद ही कभी एक महत्वपूर्ण मुद्दा है (यदि आपको आवश्यकता होने की संभावना है उस परिमाण के कई प्रमुख मूल्य शायद आप वैसे भी 64-बिट प्रकार के लिए गए थे, खासकर यदि 64-बिट आर्किटेक्चर का उपयोग करते हुए जहां ऐसे मूल्यों को कम कुशलता से संसाधित नहीं किया जाता है, तो 32-बिट वाले) हालांकि अगर आप पूरी रेंज और आवश्यकता चाहते हैं अंतरिक्ष कारणों से 32-बिट से चिपके रहने के लिए आप वेतन वृद्धि -2,147,483,647 पर शुरू कर सकते हैं।

Comments

हाँ, मुझे लगता है कि हम पहले कि जमीन को कवर किया गया है;) tehehe dba.stackexchange.com/questions/983/...

— jcolebrand

स्मालिंट अहस्ताक्षरित है (0 .. 255)। मैं आमतौर पर पूर्णांक कॉलम पर एक चेक बाधा बनाता हूं ताकि मानों का उपयोग न किया जा सके, क्योंकि अनिवार्य रूप से कोड लिखा जाएगा कि यह स्पष्ट रूप से मानता है और अजीब कीड़े उत्पन्न होंगे अगर किसी भी तरह से नकारात्मक मान रेंगता है।

— एड अवेस्टर