पहचान कॉलम या यूडीएफ जो स्पष्ट रूप से एक अद्वितीय आईडी बनाता है?

11

मैं इस बारे में एक बहस के बीच में हूं कि क्या आइडेंटिटी कॉलम मेंPRIMARY KEY से एक को बनाना बेहतर है , हमारे यूडीएफ के बाहर जो स्पष्ट रूप से एक यूनिक आईडी बनाता है।

मैं आइडेंटिटी कॉलम के लिए बहस कर रहा हूं।
मेरा साथी मैन्युअल रूप से मान उत्पन्न करने के लिए बहस कर रहा है, वह दावा करता है
- UDF को किसी अन्य टेबल पर रखकर जहां हम UDF रख सकते हैं
  - संसाधन लॉक करें
  - ID_Valueद्वारा बुलाया एक क्षेत्र के साथ एक आईडी तालिका वृद्धि1
  - इसे वैश्विक विशिष्ट पहचानकर्ता के रूप में उपयोग करें
- या id+1जब डालने के लिए मेज है
- सर्वर और / या वातावरण के बीच डेटा को ले जाना आसान नहीं है ताकि पहचान में बाधा न हो; एक DB से आगे बढ़ना जहाँ एक और समान DB का डेटा होता है, जिसमें स्टेजिंग या डमी डेटा कहते हैं। गैर-उत्पादन में परीक्षण के लिए हम कल से नीचे के सभी रिकॉर्डों को परीक्षण के लिए मंचन के लिए खींच सकते हैं।

कौन सा कार्यान्वयन अधिक समझ में आता है?

— kacalapy
स्रोत

21

आपका सहयोगी एक बेवकूफ है।

समाधान स्केलेबल नहीं होगा, यूडीएफ समवर्ती नहीं है ( इसी कारण से )। और आप बहु-पंक्ति आवेषण के साथ कैसे व्यवहार करते हैं: इसके लिए प्रति पंक्ति एक UDF कॉल की आवश्यकता होगी

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

संपादित करें:

आपके अपडेट में कहा गया है कि मूविंग डेटा नॉन-प्रोडक्शन डेटाबेस को रिफ्रेश करने के लिए है।

उस स्थिति में, आप ताज़ा करते समय पहचान कॉलम को अनदेखा कर देते हैं। आप गैर-लोडिंग लोड को आसान बनाने के लिए अपने कार्यान्वयन से समझौता नहीं करते हैं। या पहचान मूल्य परिवर्तनों को ट्रैक करने के लिए अस्थायी तालिकाओं का उपयोग करें।

या प्रक्रियाओं का उपयोग करें: हम उत्पादन से हर रात हमारे परीक्षण प्रणाली को ताज़ा करते हैं जो पूरी तरह से समस्या से बचा जाता है। (और यह सुनिश्चित करता है कि हमारे उत्पादों का बैकअप भी बहाल किया जा सकता है)

— GBN
स्रोत

11

एक पहचान मूल्य का उपयोग करें। अपनी स्वयं की अनुक्रम तालिका और अनुक्रम मान उत्पन्न करना बहुत अधिक उपरिव्यय लेगा और संख्याओं को उत्पन्न करने की कोशिश करते समय बहुत अधिक लॉकिंग और अवरोध पैदा करेगा।

एक कारण के लिए पहचान मौजूद है, इसका उपयोग करें।

जब SQL Denali सामने आती है तो यह अनुक्रमों का समर्थन करेगी जो पहचान की तुलना में अधिक कुशल होगी, लेकिन आप स्वयं कुछ अधिक कुशल नहीं बना सकते हैं।

एक पर्यावरण से दूसरे रिकॉर्ड को स्थानांतरित करने के लिए या तो सम्मिलित करते समय IDENTITY_INSERT चालू करें, या SSIS बॉक्स को चेक करें।

— mrdenny
स्रोत

यदि आप "उत्पादन" से "परीक्षण" की ओर बढ़ते हैं और एक पहचान क्षेत्र रखते हैं, तो आप डेटा पर ओवरराइटिंग या टकराने का जोखिम चलाते हैं। बस इतना ही कह रहा हूं। हाँ, यह उस दिशा में एक मुद्दा नहीं होना चाहिए , लेकिन मैं सिर्फ यह कह रहा हूँ कि ऐसा हो सकता है।

— jcolebrand

सच है, आपके पास देव, परीक्षण, qa, uat और उत्पादन में अलग-अलग पंक्ति मूल्यों के लिए समान संख्या होगी। तो क्या? यदि वे मान महत्वपूर्ण हैं (जैसे लुकअप टेबल के लिए) तो उन्हें मैन्युअल रूप से हार्ड कोड करें, जो कि एक समस्या नहीं होनी चाहिए क्योंकि आपको उन तालिकाओं में बहुत बार मान नहीं डालना चाहिए। यदि आपको टकरावों से बचने के लिए वातावरण के बीच पहचान मूल्यों को नियंत्रित करने की आवश्यकता है तो उत्पादन से पुनर्स्थापित होने पर वातावरण के बीच पहचान मूल्यों को रीसेट करें।

— मर्देनी

5

पहचान स्तंभ मुझे ठीक लगता है। मुझे यकीन नहीं है कि मैं इस तर्क का पालन करता हूं कि सर्वर के बीच डेटा स्थानांतरित करना क्यों मुश्किल है।

यदि आप चाहते हैं कि प्रत्येक पंक्ति की विश्व स्तर पर विशिष्ट पहचान हो, तो आप UUID का उपयोग कर सकते हैं, लेकिन मैं ऐसा नहीं करूंगा जब तक कि आप सुनिश्चित न हों कि वैश्विक विशिष्टता आवश्यक है - आमतौर पर यह नहीं है। यूयूआईडी का उपयोग आईडी के रूप में करने से प्रदर्शन में कमी आएगी, डिस्क स्थान की आवश्यकताओं में वृद्धि होगी और डिबगिंग को कठिन बना दिया जाएगा - क्योंकि लंबाई के कारण यूयूआईडी को याद रखना मुश्किल है, इसे फोन पर किसी को बताएं, या त्रुटि के बिना कागज पर लिख दें।

— मार्क बायर्स
स्रोत

4

साधारण संख्यात्मक आईडी के लिए, बस पहचान के साथ जाएं और मैन्युअल रूप से उन्हें उत्पन्न करने की सभी समस्याओं को भूल जाएं।

आप हमेशा एक "सुपर टेबल" बना सकते हैं जो पीके के रूप में एक पहचान का उपयोग करता है और एक प्रकार का कॉलम, और कोई अन्य जानकारी है। जब आपको एक नई आईडी की आवश्यकता होती है (आपको अलग-अलग तालिकाओं में विशिष्ट आईडीएस का मतलब है) तो बस इस तालिका में सम्मिलित करें और इसे पकड़ो SCOPE_IDENTITY()और फिर आपको आवश्यक वास्तविक तालिका में डालें।

मूल रूप से आप एक तालिका बनाते हैं: एक पहचान PK के साथ MasterIDs , जब आपको अपने Table1 में एक पंक्ति सम्मिलित करने की आवश्यकता होती है, INSERT INTO MasterIDsऔर उस पंक्ति द्वारा उपयोग की गई पहचान प्राप्त करें SCOPE_IDENTITY()और फिर PK1 के रूप में उस मान का उपयोग करके तालिका 1 में सम्मिलित करें ।

तालिका 1 में एक गैर-पहचान इंट पीके होगा। आप Table2 आदि में सम्मिलित करने के लिए एक ही प्रक्रिया करेंगे। SQL सर्वर को MasterIDs तालिका में पहचान मानों को प्रबंधित करने दें , जिसे आप बाद में अपनी अन्य तालिकाओं में उपयोग कर सकते हैं। MasterIDs में अन्य तालिकाएँ शामिल हो सकती हैं, जैसे प्रकार (ताकि आप जान सकें कि तालिका, Table1 या Table2, आदि, उस पहचान मूल्य का उपयोग करती है।

— पॉल व्हाइट 9
स्रोत

3

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

— जो फिलिप्स
स्रोत

2

अपने परिदृश्य को फिट करने के लिए पहचान बनाई गई थी। आपके पास सर्वर / वातावरण डेटा विनिमय के लिए प्रतिकृति जैसे उपकरण हैं जो इसे एक साथ रखते हैं।

1

मैंने अभी-अभी काम का एक टुकड़ा पूरा किया है जहाँ मैंने identityएक सामान्य intक्षेत्र के साथ एक SQL सर्वर कॉलम को बदल दिया है और खुद को Id आवंटन नियंत्रित किया है।

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

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

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

— निशान
स्रोत

0

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

अद्यतन: के बाद मैंने देखा है यह मैं निश्चित रूप से UniqueIdentifier की ओर झुक। यह Bigint पहचान का कोई वास्तविक लाभ और UNIQUEIDENTIFIER के लिए लाभ का एक गुच्छा दिखाता है! SQL सर्वर के विभिन्न संस्करणों का एक अलग परिणाम हो सकता है। सभी डेटाबेस और सिस्टम (मजबूती) में एक अद्वितीय आईडी होने में सिर्फ सुंदरता है! जैसे ही आप चाहते हैं, डेटा स्थानांतरित करें, कॉपी करें! https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/

— ह्रींजे बत्रनेक
स्रोत

एक 64 बिट INT लंबे समय तक

— चलेगा