ग्रिड प्राथमिक/विदेशी कुंजी दुविधा एसक्यूएल सर्वर

Question

मुझे अपनी प्राथमिक कुंजी को पहचानने से गुड तक बदलने की दुविधा का सामना करना पड़ रहा है। मैं अपनी समस्या सीधे रखूंगा। यह पीओएस और बैक ऑफिस कार्यक्षमता के साथ एक विशिष्ट खुदरा प्रबंधन ऐप है। लगभग 100 टेबल है। डेटाबेस अन्य डेटाबेस के साथ सिंक्रनाइज़ करता है और नया डेटा प्राप्त/भेजता है।

अधिकांश तालिकाओं में लगातार आवेषण, अद्यतन या उन पर निष्पादित बयान का चयन नहीं होता है। हालांकि, कुछ में लगातार आवेषण होते हैं और उन पर चयन करते हैं, उदाहरण के लिए। उत्पाद और ऑर्डर टेबल।

कुछ तालिकाओं में 4 विदेशी कुंजी हैं। अगर मैंने अपनी प्राथमिक कुंजी को 'int' से 'guid' में बदल दिया है, तो कई विदेशी कुंजी वाले टेबल से डेटा डालने या क्वेरी करने पर प्रदर्शन समस्या होगी। मुझे पता है कि लोगों ने कहा है कि इंडेक्स को खंडित किया जाएगा और 16 बाइट एक मुद्दा है।

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

मैं इस पर अपने विचारों की बहुत सराहना हो जाएगा ... पूर्णांक से अधिक guid के उपयोग की

Answer 1

GUID आपकी प्राथमिक कुंजी के लिए एक प्राकृतिक विकल्प प्रतीत हो सकता है - और यदि आपको वास्तव में जरूरी है, तो आप शायद तालिका के प्राथमिक कुंजी के लिए इसका उपयोग करने का बहस कर सकते हैं। मैं को दृढ़ता से अनुशंसा करता हूं किक्लस्टरिंग कुंजी के रूप में GUID कॉलम का उपयोग करें, जो SQL सर्वर डिफ़ॉल्ट रूप से करता है, जब तक कि आप इसे विशेष रूप से नहीं बताते।- उम्मीदवार कुंजी है जो विशिष्ट और मज़बूती से अपनी तालिका में प्रत्येक पंक्ति की पहचान करता है में से एक

1) प्राथमिक कुंजी एक तार्किक निर्माण है:

आप वास्तव में अलग दो मुद्दों रखने की जरूरत है। यह कुछ भी हो सकता है, वास्तव में - एक आईएनटी, एक GUID, एक स्ट्रिंग - चुनें जो आपके परिदृश्य के लिए सबसे ज्यादा समझ में आता है।

2) क्लस्टरिंग कुंजी (स्तंभ या स्तंभों कि मेज पर "क्लस्टर सूचकांक" को परिभाषित) - यह, यहाँ एक शारीरिक भंडारण से संबंधित बात है, और एक छोटे से, स्थिर, बढ़ती डेटा प्रकार आपका सबसे अच्छा विकल्प - INT या BIGINT आपके डिफ़ॉल्ट विकल्प के रूप में है।

डिफ़ॉल्ट रूप से, SQL सर्वर तालिका पर प्राथमिक कुंजी क्लस्टरिंग कुंजी के रूप में भी उपयोग की जाती है - लेकिन उस तरह होने की आवश्यकता नहीं है! पिछली GUID- आधारित प्राथमिक/क्लस्टर कुंजी को दो अलग-अलग कुंजी में विभाजित करते समय मैंने व्यक्तिगत प्रदर्शन लाभ व्यक्तिगत रूप से देखा है - GUID पर प्राथमिक (तार्किक) कुंजी, और क्लस्टरिंग (ऑर्डरिंग) कुंजी को अलग-अलग INT पहचान (1, 1) कॉलम।

Kimberly Tripp - इंडेक्सिंग की रानी - और अन्य ने कई बार कहा है - क्लस्टरिंग कुंजी के रूप में एक GUID इष्टतम नहीं है, क्योंकि इसकी यादृच्छिकता के कारण, यह बड़े पैमाने पर पेज और इंडेक्स विखंडन और आम तौर पर बुरा प्रदर्शन।

हाँ, मुझे पता है - SQL Server 2005 और 0 में newsequentialid() है - लेकिन यह भी वास्तव में और पूरी तरह अनुक्रमिक नहीं है और इस प्रकार GUID के समान समस्याओं से भी पीड़ित है - बस थोड़ा सा प्रमुख।

फिर विचार करने के लिए एक और मुद्दा है: तालिका पर क्लस्टरिंग कुंजी आपके टेबल पर प्रत्येक और गैर-क्लस्टर इंडेक्स पर प्रत्येक प्रविष्टि में भी जोड़ा जाएगा - इस प्रकार आप वास्तव में यह सुनिश्चित करना चाहते हैं कि यह छोटा हो मुमकिन। आम तौर पर, 2+ अरब पंक्तियों के साथ एक आईएनटी विशाल बहुमत के लिए पर्याप्त होना चाहिए - और क्लस्टरिंग कुंजी के रूप में एक GUID की तुलना में, आप डिस्क पर और सर्वर मेमोरी में सैकड़ों मेगाबाइट स्टोरेज को बचा सकते हैं।

त्वरित गणना - INT बनाम GUID का उपयोग कर के रूप में प्राथमिक और क्लस्टरिंग कुंजी: 1'000'000 पंक्तियों (3.8 एमबी बनाम 15.26 एमबी)

6 nonclustered सूचकांक

• बेस तालिका (22.89 एमबी बनाम 91.55 एमबी)

कुल: 25 एमबी बनाम 106 एमबी - और कि बस एक ही मेज पर है!

विचार के लिए कुछ और खाना - Kimberly Tripp द्वारा उत्कृष्ट सामग्री - इसे पढ़ें, इसे फिर से पढ़ें, इसे पचाना! यह वास्तव में एसक्यूएल सर्वर अनुक्रमण सुसमाचार है।

• GUIDs as PRIMARY KEY and/or clustered key
• The clustered index debate continues
• Ever-increasing clustering key - the Clustered Index Debate..........again!

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

Answer 2

नुकसान: जब मिलती है में प्रयोग किया जाता

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

उत्पन्न GUIDs (SQL 2005 को जैसे, newsequentialid()) सर्वश्रेष्ठ प्रदर्शन के लिए आंशिक रूप से अनुक्रमिक होना चाहिए और क्लस्टर अनुक्रमित

और अधिक विस्तार के लिए

के उपयोग को सक्षम करने के:

http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html

http://blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/

Answer 3

पीयू के लिए GUID या int का उपयोग वास्तव में परिदृश्य पर निर्भर करता है। आईएनटी से GUID में एक प्रदर्शन हिट बदल जाएगा। GUID एक आईएनटी से 4 गुना बड़ा है। GUID का उपयोग करने के पेशेवरों और विपक्ष के बारे में here का एक अच्छा लेख है।

आपको इंटीग्रर्स से वैसे भी क्यों बदलना है?

Answer 4

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

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

Answer 5

मेरा लेना है: अंदरूनी पीके के रूप में ऑटोइनक्रिएटिव int का उपयोग करें और प्रत्येक प्राथमिक तालिका पर एक अद्वितीय ग्रिड कॉलम है जिसका उपयोग आप डेटाबेस में पंक्तियों को स्थानांतरित करने के लिए करते हैं।

डेटा निर्यात करते समय इस कॉलम में शामिल हों, int निर्यात न करें, और डेटा आयात करते समय इसे वापस स्पर्श करें।

विशेष रूप से बड़ी मात्रा में, int बहुत छोटे और तेज़ होते हैं।