ईमेल पता अद्वितीय या प्राथमिक कुंजी?

Question

मैं डेटाबेस में एक नौसिखिया हूँ। मैंने चारों ओर पढ़ा और पता चला कि प्राथमिक कुंजी के रूप में ईमेल पते का उपयोग करना शायद एक महान विचार नहीं है क्योंकि स्ट्रिंग तुलनाएं धीमी हैं जो कि जटिल जोड़ में प्रदर्शन को प्रभावित करती हैं और यदि कोई ईमेल बदलता है तो मुझे उन सभी विदेशी कुंजियों को बदलना होगा जिनके लिए बहुत कुछ आवश्यक है प्रयास का।

लेकिन अगर मेरी उपयोगकर्ता तालिका में प्रत्येक उपयोगकर्ता के पास ईमेल पता होना चाहिए और उन ईमेल पते में से प्रत्येक अद्वितीय होना चाहिए, तो क्या ईमेल स्तंभ प्रत्यय पर एक अद्वितीय सूचकांक जोड़ना होगा? चूँकि afaik अनूठे फ़ील्ड शून्य मानों की अनुमति देते हैं, जबकि मुझे प्रत्येक उपयोगकर्ता के लिए ईमेल पता होना आवश्यक है, अशक्त मानों की अनुमति नहीं। क्या मुझे यहाँ कुछ याद आ रहा है? या मुझे लगता है कि ईमेल स्तंभ को अद्वितीय बनाने के लिए और यह सुनिश्चित करने के लिए कि सर्वर पर डेटा सत्यापन के दौरान उपयोगकर्ता एक ईमेल पता दर्ज करता है ताकि प्रत्येक उपयोगकर्ता के पास एक हो?

Comments

जब कोई उपयोगकर्ता अपना ईमेल पता बदलता है, तो क्या होता है - जैसे वे नौकरी बदलते रहेंगे

— user151019

स्ट्रिंग तुलना केवल धीमी नहीं होती है, तार भी एक पूर्णांक की तुलना में बड़े होते हैं, और इसलिए आप स्मृति में एक पृष्ठ पर कम फिट कर सकते हैं, प्रश्नों के लिए अपने तार्किक रीड को धक्का दे सकते हैं।

— निर्मम एक

Answer 1

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

एक उम्मीदवार कुंजी एक ऐसी चीज है जो विशिष्ट रूप से एक तालिका में एक पंक्ति को पहचानती है, उम्मीदवार की SQL में से एक में आमतौर पर एक प्राथमिक कुंजी के रूप में उपयोग किया जाता है (मुझे वास्तव में कभी भी समझ नहीं आया कि सीके में से एक को दूसरों की तुलना में "बेहतर" क्यों माना जाता है, लेकिन यह एक और है कहानी), और शेष ck अद्वितीय अवरोध बन जाता है।

एक अद्वितीय बाधा का उपयोग उसी तरह किया जा सकता है जैसे प्राथमिक कुंजी कर सकता है। विचार करें:

create table A ( x ... not null
               , y ... not null
               , z ... not null
               ,     unique (x)
               ,     primary key (y,z) );

create table B ( x ...
               ,   ...
               ,     foreign key (x) references A (x) );

create table C ( y ...
               , z ...
               ,   ...
               ,     foreign key (y, z) references A (y, z) );  

बी अद्वितीय बाधा का संदर्भ देता है और सी प्राथमिक कुंजी बाधा का संदर्भ देता है।

नहीं NULL अभी तक एक और तरह की बाधा नहीं है। आपके मामले में आप इसे अद्वितीय घोषित किए बिना ईमेल के लिए लागू कर सकते हैं।

आपकी पोस्ट का अगला पहलू एक कुंजी की स्थिरता की चिंता करता है, एक कुंजी स्थिर होनी चाहिए (लेकिन इसका मतलब यह नहीं है कि यह कभी नहीं बदल सकता है, यह अपरिवर्तनीय नहीं है)। कुछ DBMS को UPDATE CASCADE पर लागू किया जाता है, जो इस तरह के ऑपरेशन के लिए मददगार हो सकता है, फिर भी यदि कुंजी आपके मॉडल के चारों ओर वितरित की जाती है, तो इसे अपडेट करने में दर्द होगा।

आपके मामले में मैं संभवतः प्राथमिक कुंजी के रूप में एक और उम्मीदवार कुंजी चुनूंगा, और ईमेल को नॉट नॉट और यूनीक्वाय घोषित करूंगा।

Comments

SQL सर्वर में आप FK के रूप में एक अद्वितीय सूचकांक को संदर्भित कर सकते हैं।

— मार्टिन स्मिथ

मेरे पास sql तक पहुंच नहीं है इसलिए मैं खुद के लिए जांच नहीं कर सकता, क्या यह एक अद्वितीय सूचकांक बनाते समय एक विशिष्ट बाधा पैदा करता है?

— लेनार्ट

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

— मार्टिन स्मिथ

यह थोड़ा अजीब है, फिर भी sql मानक में इंडेक्स का उल्लेख नहीं किया गया है, जबकि चाबियाँ इसका एक केंद्रीय हिस्सा हैं। किसी भी तरह, जानकारी के लिए धन्यवाद।

— लेनार्ट

यह ध्यान देने योग्य है कि यदि आपके ईमेल में बहुत सारे रिकॉर्ड विदेशी हैं, तो अपडेट कैस्केड होने पर उन सभी रिकॉर्डों को अपडेट करने में थोड़ा समय लग सकता है।

— cimmanon

Answer 2

हाँ EmailAddress कॉलम पर एक अद्वितीय सूचकांक होना ठीक होना चाहिए। एकमात्र समस्या यह होगी कि यदि किसी ने आपकी सेवा के लिए साइन अप करने के बाद ईमेल पता छोड़ दिया, लेकिन आपको नहीं बताया, तो फिर जो कोई भी ईमेल पते का मालिक है वह साइन अप करने की कोशिश करता है। लेकिन यह एक बहुत ही दुर्लभ बढ़त का मामला है।

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

Comments

यह SQL सर्वर के बारे में सच नहीं है। आप whereखंडों के साथ सूचकांक बना सकते हैं , उदाहरण के लिए, आप NULLसूचकांक से मूल्यों को बाहर करने की अनुमति देते हैं ।

— Kirk Woll

कथन SQL Server allows a single NULL valueअभी भी सत्य है। यह नहीं कहता कि कई NULLमान प्राप्त करने का कोई तरीका नहीं है। मुझे लगता है कि उत्तर को सरल रखने और अतिरिक्त विवरण (जैसे फ़िल्टर किए गए अनुक्रमित) की व्याख्या नहीं करने की कोशिश कर रहा था।

— ब्रैंडन

हाँ, मैं फ़िल्टर्ड अनुक्रमित के पूरे खरगोश को कबूतर कर सकता था लेकिन एक साधारण प्रश्न को आमतौर पर एक सरल उत्तर की आवश्यकता होती है। डेटाबेस प्लेटफॉर्म और संस्करण के बिना मैं अपने उत्तर सामान्य रखता हूं।

— मन्दिनी

Answer 3

EmailAddress पर अद्वितीय अनुक्रमणिका होना ठीक है।

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

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