क्या विभाजन कुंजी भी प्राथमिक कुंजी का हिस्सा होना चाहिए?


24

मैं एक स्तंभ पर आधारित तालिका का विभाजन कर रहा हूं जो प्राथमिक कुंजी नहीं है? मैंने आज कुछ परस्पर विरोधी जानकारी पढ़ी है कि क्या विभाजन कॉलम प्राथमिक कुंजी का एक हिस्सा होना चाहिए। मेरी आंत कहती है कि नहीं, लेकिन मैं 100% निश्चित नहीं हूं। तो सवाल ...

  1. विभाजन कॉलम प्राथमिक का हिस्सा होना चाहिए? यह एक तरह से या दूसरे की सिफारिश की है?
  2. क्या मुझे विभाजन कुंजी के लिए एक इंडेक्स बनाना है, या DBMS इसे अपने आप करता है?

जवाबों:


11

हर्गिज नहीं।

विभाजन के लिए सबसे आम परिदृश्यों में से एक दिनांक फ़ील्ड का उपयोग करना है, जो आपके PK से पूरी तरह से असंबंधित है।

उदाहरण के लिए, यदि आपके पास Ordersफ़ील्ड के साथ एक तालिका है, तो आप OrderDateमहीने और वर्ष के आधार पर सबसे अधिक विभाजन की संभावना रखेंगे OrderDate

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

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

संपादित करें

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


10
मुझे पता है कि यह पुराना है, लेकिन यह मुझे गलत रास्ते पर ले जाता है इसलिए मुझे लगा कि मैं दूसरों के लिए टिप्पणी करूंगा। यदि आप विभाजन सुविधा के SWITCH क्षमताओं का उपयोग करना चाहते हैं तो विभाजन कॉलम को प्राथमिक कुंजी में होना चाहिए। यदि यह प्राथमिक कुंजी में नहीं है, तो आपको यह त्रुटि Partition columns for a unique index must be a subset of the index key.
मिलेगी

मैं @Vaccano से सहमत हूं
san

3

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

ऐसे कई प्रकार के परिदृश्य हैं जहां विभाजन योजना प्राथमिक कुंजी के पहले कॉलम का अनुसरण करती है - उदाहरण के लिए डेटा वेयरहाउस परिदृश्य में जहां तथ्य तालिका की स्नैपशॉट तिथि आमतौर पर विभाजन कुंजी के साथ प्राथमिक कॉलम में भी होती है।

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

लेकिन इसकी आवश्यकता नहीं है।


ठीक है, सामान की एक पूरी बहुत आवश्यकता नहीं है। यहां तक ​​कि अनुक्रमण भी एक आवश्यकता नहीं है! कार्यात्मक रूप से समझ बनाने के लिए, एक उम्मीदवार कुंजी के प्रमुख कॉलम पर विभाजन करना पड़ता है। अन्यथा ऐप आर्किटेक्ट टेबल का उपयोग कैसे करेगा?
srini.venigalla

@ srini.venigalla यह एक सामान्य मामला है, लेकिन एक और सामान्य मामला (समान रूप से ऐसा है?) किसी ऐसी चीज़ पर विभाजन करना है जो प्राथमिक या उम्मीदवार कुंजी का हिस्सा नहीं है - क्योंकि विभाजन अक्सर संग्रह के लिए उपयोग किया जाता है, एक समाप्ति तिथि हो सकती है एक अच्छा विभाजन विकल्प। लेकिन ऐसा कुछ भी नहीं है जिसका तात्पर्य है कि एक कुंजी का हिस्सा हो सकता है। विभाजन एक निम्न-स्तर की विशेषता है जो बहुत ही सामान्य है और यहाँ कम से कम दो अलग और परस्पर विरोधी उपयोग पैटर्न हैं, जिनमें से दोनों के आसपास वैध सर्वोत्तम प्रथाएं हैं।
केड रूक्स

0

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

तो जवाब है, हां, यह पीके का हिस्सा बनना पसंद करता है। यदि एक और कुंजी नहीं है, जो पीके होने के लिए समान रूप से अच्छा है।


कैंडिडेट कुंजी के बारे में कभी नहीं सुना। इसे Create / Alter टेबल स्टेटमेंट में कैसे निर्दिष्ट करता है?
एंग्रीहैकर

उम्मीदवार कुंजी प्राथमिक कुंजी होने के लिए योग्य एक और कुंजी है। उदाहरण के लिए, आईडी प्राथमिक कुंजी है। लेकिन एक ही तालिका में, उदाहरण के लिए एक और कॉलम। PERSON_ID भी विशिष्ट रूप से एक पंक्ति की पहचान कर सकती है, जिसे कैंडिडेट कुंजी कहा जाता है। 2 और 3 के सामान्यीकरण नियमों को सभी उम्मीदवार कुंजी के खिलाफ भी पकड़ना चाहिए।
srini.venigalla

समझ लिया। मेरे प्रश्न के दूसरे भाग के बारे में क्या?
एंगरहैकर

किसी भी अन्य सूचकांक के समान। उदाहरण: CREATE INDEX IX_ProductVendor_VendorID ON Purchasesing.ProductVendor (BusinessEntityID);
श्रीनि.वेनगल्ला

4
यह बिल्कुल गलत है। आप कई क्षेत्रों पर विभाजन कर सकते हैं जो पीके से संबंधित नहीं हैं, जैसे कि OrderDate। क्या आपके पास अपने दावों का समर्थन करने के लिए कुछ है?
जेएनके जूल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.