एक कुंजी को स्पष्ट क्यों किया जाना चाहिए?

Question

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

Comments

क्या आपका मतलब है कि अगर आपके पास एक अद्वितीय कुंजी है, तो एक प्राथमिक होने में परेशान क्यों करें?

— वेरेस

बस उन्हें क्यों घोषित किया जाता है? यह बहुत मददगार लगता है, लेकिन क्या वास्तव में एक डेटाबेस होना आवश्यक है जो कार्य करता है?

— dsaxton

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

— एंड्री एम

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

— थोरबजोरन रावन एंडरसन

Answer 1

आप स्पष्ट रूप से सुझाव दे रहे हैं कि CONSTRAINTडेटाबेस में s को एप्लिकेशन द्वारा लागू किया जाना चाहिए जो उस डेटाबेस तक पहुंचते हैं?

यह एक बुरा (बुरा, बुरा ...) विचार है कई कारण हैं ।

1) यदि आप "रोल-योर-कॉन्स्टेंट" इंजन (यानी आपके एप्लिकेशन कोड के भीतर) का निर्माण कर रहे हैं, तो आप केवल Oracle / SQL Server / MySQL / PostgreSQL / <। Whoever ...> खर्च कर रहे हैं। साल लेखन। उनका CONSTRAINT कोड उन वर्षों में परीक्षण किया गया है, जो वास्तव में लाखों अंत-उपयोगकर्ताओं द्वारा देखे गए हैं ।

2) आपके और आपकी टीम के लिए पूरे सम्मान के साथ, आप इसे कुछ वर्षों में भी सही नहीं मानेंगे - यहाँ से , अकेले MySQL कोड की कीमत 40 मिलियन डॉलर है। और MySQL उपरोक्त 3 सर्वरों में से सबसे सस्ता है, और वे CHECK CONSTRAINTs को भी लागू नहीं करते हैं। जाहिर है, आरआई (रेफरेंशियल इंटीग्रिटी) को पूरी तरह से सही पाना मुश्किल है।

मैं ओरेकल फ़ोरम का लगातार उपयोग करता था और मैं आपको कई बार बता नहीं सकता कि कुछ गरीब प्रबंधक / प्रोग्रामर ने उस पर एक प्रोजेक्ट किया है, जहाँ प्रतिभा ने अपना काम करने से पहले "उज्ज्वल" विचार किया था जो आप सुझाते हैं। ।

जोनाथन लुईस (उन्होंने ओरेकल ऑप्टिमाइज़र के मूल सिद्धांतों पर 550 पृष्ठ की किताब लिखी ) के रूप में कोई नहीं देता है। एक अन्य पुस्तक में उनके डिजाइन डिजास्टर के 2 (" द स्टोरी ऑफ द ओक टेबल " - ओक टेबल ओरेकल विशेषज्ञों का एक समूह है)

2. हम Oracle की बाधा जाँच क्षमताओं का लाभ लेने के बजाय आवेदन स्तर पर डेटा अखंडता की जाँच करेंगे।

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

आप इस बारे में अधिक पढ़ सकते हैं कि एप्लिकेशन स्तर पर डेटा CONSTRAINTs को लागू करने के लिए यहां , यहां और यहां पागलपन की कोई कमी नहीं है ।

विशेष रूप से आपके प्रश्न का उत्तर देने के लिए:

बस उन्हें क्यों घोषित किया जाता है? यह बहुत उपयोगी लगता है, लेकिन क्या वास्तव में एक डेटाबेस होना आवश्यक है जो कार्य करता है

कारण यह है कि KEYरों (या तो PRIMARY, FOREIGN, UNIQUEया सिर्फ साधारण INDEXते) घोषित किया गया है, जबकि यह है कि है, सख्ती से नहीं है, आवश्यक एक डेटाबेस उन्हें करने के लिए के लिए इसके लिए कार्य करते हैं बिल्कुल आवश्यक हो तो उन्हें कार्य करने के लिए इसके लिए घोषित करने के लिए अच्छी तरह से ।

Comments

आपके उत्तर के लिए धन्यवाद। मुझे संभवतः इसे पूरी तरह से समझने के लिए और जानने की आवश्यकता होगी। (मैं वास्तव में एक टीम के हैं नहीं है, मैं तो बस जिज्ञासा से बाहर डेटाबेस के बारे में सीख रहा हूँ।)

— dsaxton

कुछ पुस्तकें पढ़ें (दिनांक, गार्सिया-मोलिना ...) और हमारे पास वापस आएँ यदि आपके पास विशिष्ट प्रश्न हैं (ऐसे प्रश्न जो अत्यधिक व्यापक हैं, तो उन्हें यहाँ से हटा दिया गया है)। ps मंच में आपका स्वागत है :-)

— Vérace

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

— jpmc26

Answer 2

जब आप डेटाबेस में एक कुंजी बनाते हैं, तो DBMS इंजन प्रमुख विशेषताओं पर एक विशिष्टता बाधा को लागू करता है। यह कम से कम तीन संबंधित उद्देश्यों को पूरा करता है:

• डेटा अखंडता: डुप्लिकेट डेटा को मुख्य विशेषताओं में दर्ज नहीं किया जा सकता है। इसलिए चाबियों पर निर्भरता की गारंटी दी जाती है।
• पहचान: उपयोगकर्ता डेटा को सही ढंग से पहचानने और अद्यतन करने के साधन के रूप में कुंजियों पर भरोसा करने में सक्षम हैं।
• अनुकूलन: जानकारी (मेटाडेटा) जिसके बारे में विशेषताएँ अद्वितीय हैं DBMS क्वेरी ऑप्टिमाइज़र के लिए उपलब्ध हैं। यह जानकारी ऑप्टिमाइज़र को कुछ तरीकों से क्वेरी निष्पादन को आसान बनाने की अनुमति देती है ताकि क्वेरी तेजी से निष्पादित हो।

Answer 3

मैं मौजूदा उत्कृष्ट उत्तरों में एक पहलू जोड़ूंगा: प्रलेखन। अक्सर यह देखना महत्वपूर्ण होता है कि किसी इकाई की पहचान करने के लिए आप किस प्रकार की चाबियों का उपयोग कर सकते हैं। अद्वितीय कॉलम का कोई भी संयोजन एक उम्मीदवार कुंजी है।

प्राथमिक कुंजी व्यवहार में एक विशेष रूप से उपयोगी अवधारणा है।

चाहे आप एक कुंजी लागू करते हैं या नहीं (आपको शायद चाहिए) प्रलेखन अपने आप में मूल्यवान है।

Comments

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

— रीइनरईयरपोस्ट

@reinierpost मैं पूरी तरह से सहमत हूँ। दस्तावेज़ के लिए डेटा सबसे मूल्यवान वस्तु है और इसे साफ रखना क्योंकि यह हमेशा बनी रहती है। कोड बदल सकते हैं; यह अधिक क्षणिक होता है।

— बूट

@reinierpost - एक ऐसी कंपनी के लिए परामर्श दिया गया जो एक बड़े यूरोपीय देश के पूरे रेल बुनियादी ढांचे के लिए सॉफ्टवेयर की आपूर्ति करती थी (बड़े-बड़े विचाराधीन विजेट्स) और मैंने कहा, "हुम, मैं सिर्फ एक FOREIGN KEYपरिभाषा पाने के लिए परिभाषाओं की जांच करने के लिए एक क्वेरी चलाऊंगा।" सिस्टम के लिए महसूस करें ”। मेरी क्वेरी वापस ज़िप !!! सुनिश्चित करें कि मेरी एसक्यूएल गलत रही होगी, मैंने एक वरिष्ठ प्रोग्रामर से इसका उल्लेख किया। गर्व के साथ (कोई कम नहीं) उन्होंने घोषणा की (जैसे कि वह एक नए जन्मे बेटे को पेश कर रहे थे) कि सिस्टम के पास कोई एफके नहीं है क्योंकि "सभी खोजें PRIMARY KEYs पर हैं " - (अप्रासंगिक)। <दोह ...> एक ला होमर सिम्पसन!

— Vérace

Answer 4

एक और कारण है कि आपको कुछ अंदरूनी अनुप्रयोग-कोड के बजाय CONSTRAINT का उपयोग करना चाहिए:

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

पुनश्च: बेशक आप ट्रिगर बना सकते हैं, लेकिन वे आम तौर पर धीमी गति से होते हैं (CONSTRAINTS की तुलना में)।