SQL सर्वर में एक प्राथमिक कुंजी आवश्यक है?

Question

यह एक बहुत भोली और बेवकूफ सवाल हो सकता है, लेकिन मैं इसे पूछने के लिए वैसे भी

मैं कई क्षेत्रों, जिनमें से कोई भी अद्वितीय हैं, और एक प्राथमिक कुंजी है, जो स्पष्ट रूप से है के साथ एक मेज है जा रहा हूँ।

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

Answer 1

आवश्यक? नहीं। दृश्यों के पीछे प्रयुक्त? खैर, यह डिस्क पर सहेजा गया है और पंक्ति कैश, आदि में रखा गया है। हटाने से आपके प्रदर्शन में थोड़ा वृद्धि होगी (नोटिस के लिए मिलीसेकंद परिशुद्धता के साथ एक घड़ी का उपयोग करें)।

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

निष्कर्ष: के बाद से एक पी होने (भले ही एटीएम उपयोग नहीं किया जाता) की लागत इतना छोटा है, रहने दो।

Answer 2

परिभाषित होने पर प्राथमिक कुंजी अनुक्रमण और रिश्तों के लिए डेटाबेस के भीतर प्रदर्शन में सुधार करने में मदद करेगी।

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

Answer 3

मेरे पास प्राथमिक कुंजी के बिना कभी भी टेबल नहीं होगी। मान लीजिए कि आपको कभी भी एक डुप्लिकेट हटाने की आवश्यकता है - आप कैसे पहचानेंगे कि किसको निकालना है और किसके पास रखना है?

Answer 4

एक पीके आवश्यक नहीं है।

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

एचटीएच!
थॉमस

Answer 5

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

Answer 6

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

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

Answer 7

रूप SQLMenace कहा, क्लस्टर सूचकांक तालिका के भौतिक लेआउट के लिए एक महत्वपूर्ण स्तंभ है। इसके अलावा, एक क्लस्टर इंडेक्स होने के साथ, विशेष रूप से एक अच्छी तरह से चुने गए एक को एक पतला कॉलम जैसे एक पूर्णांक पीके पर, वास्तव में सम्मिलित प्रदर्शन बढ़ाता है।

Answer 8

क्या आपके पास कोई विदेशी कुंजी है, क्या आप कभी पीके पर शामिल होते हैं?

यदि इसका उत्तर नहीं है, और आपका ऐप कभी भी पीके द्वारा तालिका से किसी आइटम को पुनर्प्राप्त नहीं करता है, और कोई प्रश्न कभी भी उस खंड में इसका उपयोग नहीं करता है, इसलिए आपने पीके रखने के लिए केवल एक पहचान कॉलम जोड़ा है, फिर :

• पी अपने आप में कोई मूल्य नहीं लेता है, लेकिन कोई नुकसान या तो
• तथ्य यह है कि पी के बहुत संभावना संकुल अनुक्रमणिका भी है करता है .. यह निर्भर करता है।

आप एनसी अनुक्रमित है, तो सच है कि आप एक संकीर्ण कृत्रिम क्लस्टर कुंजी (पहचान पी) है कि उन अनुक्रमित संकीर्ण रखने में सहायक है (CDX कुंजी हर एनसी पत्ती स्लॉट्स में reproduced है)। तो एक पीके, भले ही कभी भी उपयोग न किया जाए, यदि आपके पास महत्वपूर्ण एनसी इंडेक्स हैं तो सहायक होता है।

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

और अंत में, यदि तालिका शायद ही कभी पूछताछ की जाती है लेकिन अक्सर तब लिखा जाता है कि यह एक हेप (कोई क्लस्टर्ड कुंजी नहीं) के लिए एक अच्छा उम्मीदवार हो सकता है क्योंकि ढेर में ढेर इतने बेहतर होते हैं। Comparing Tables Organized with Clustered Indexes versus Heaps देखें।

Answer 9

प्राथमिक कुंजी वास्तव में आपके डोमेन मॉडल की एक संपत्ति है, और यह विशिष्ट रूप से किसी डोमेन ऑब्जेक्ट का उदाहरण पहचानती है।

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

मुझे प्राथमिक कुंजी के बिना तालिका बनाने का बहुत अच्छा कारण होना चाहिए।

Answer 10

तार्किक मॉडल में, एक तालिका में कम से कम एक कुंजी होनी चाहिए। मनमाने ढंग से निर्दिष्ट करने का कोई कारण नहीं है कि चाबियों में से एक 'प्राथमिक' है; सभी चाबियाँ बराबर हैं। यद्यपि 'प्राथमिक कुंजी' की अवधारणा टेड कोड के शुरुआती काम पर वापस देखी जा सकती है, लेकिन गलती को उठाया गया था, जिसे सिद्धांत सिद्धांत में लंबे समय से सही किया गया है।

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

एसक्यूएल में, PRIMARY KEY का उपयोग करके इसके प्रभाव पर उदा। NOT NULL, UNIQUE, तालिका के विदेशी कुंजी के लिए डिफ़ॉल्ट संदर्भ। SQL सर्वर में, PRIMARY KEY का उपयोग करके स्वयं पर प्रभाव पड़ता है उदा। तालिका की क्लस्टर सूचकांक। हालांकि, इन सभी मामलों में, अंतर्निहित व्यवहार विशिष्ट वाक्यविन्यास का उपयोग करके स्पष्ट किया जा सकता है।

आप एसक्यूएल में कुंजियों को लागू करने के लिए संयोजन में UNIQUE (इंडेक्स की बजाय बाधा) और NOT NULL का उपयोग कर सकते हैं। इसलिए, नहीं, SQL सर्वर में प्राथमिक कुंजी (या यहां तक ​​कि PRIMARY KEY) आवश्यक नहीं है।