SQL सर्वर

Question

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

Answer 1

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

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

UPDATE table 
SET secondaryID = secondaryID - 1 
WHERE secondaryID > (SELECT secondaryID FROM table WHERE primaryID = [id to delete]); 

DELETE FROM table 
WHERE primaryID = [id to delete]; 

मैं दृढ़ता से इस तरह के एक अभ्यास को हतोत्साहित - अगर आपकी आईडी 'लापता' रहे हैं, क्योंकि नष्ट कर दिया रिकॉर्ड के मूल्यों, सॉफ्टवेयर बल्कि इन मूल्यों के अस्तित्व के लिए परीक्षण करना चाहिए बस बाहर wigging की तुलना में।

Answer 2

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

यदि आपको आदेश दिए गए आदेशों का ट्रैक रखने की आवश्यकता है तो दिनांक/समय टिकट का उपयोग क्यों न करें।

आपको अपने डिज़ाइन को फिर से सोचने की आवश्यकता है।

Answer 3

आप आईडी का उपयोग केवल पहचानकर्ता से अधिक के रूप में कर रहे हैं। यदि ऐसा है, तो आप एक ऑटो वृद्धि क्षेत्र का उपयोग करने में सक्षम नहीं होंगे। आपको इसे अपने कोड में संभालना होगा।

Answer 4

ऐसा नहीं है कि आईडी कैसे काम करती हैं, और नहीं कि उन्हें कैसे काम करना चाहिए। आईडी को कभी नहीं बदला जाना चाहिए, या सभी लिंक्ड जानकारी गलत पंक्ति को इंगित करेगी।

इसके बजाय, आप "बाहरी_आईडी" कॉलम को क्यों नियंत्रित नहीं करते हैं? या उन्हें अपनी क्वेरी में गतिशील रूप से नंबर दें (एक गणना कॉलम के साथ?)

Answer 5

यह कई तरीकों से इतना बुरा विचार है। मैं बहस कर रहा हूं अगर मुझे आपको यह दिखाना चाहिए कि यह कैसे करना है। एक बार सेट होने के बाद पंक्ति की पहचान बदलने का कोई कारण नहीं होना चाहिए।

यदि आप शायद अपने पीके पहचानकर्ता के रूप में गलत फ़ील्ड का उपयोग कर रहे हैं। मैं यहां एक धारणा बना रहा हूं कि आप अपने पीके क्षेत्र के बारे में बात कर रहे हैं जो एक पहचान कॉलम भी है।

ध्यान रखें कि यदि आप अपनी संपर्क तालिका से लिंक करने वाली कोई भी टेबल बनाते हैं और आप अपना आईडी बदलना शुरू करते हैं तो आपको उन सभी तालिकाओं को भी अपडेट करना होगा। जो महंगा होगा ...

Answer 6

यह प्रत्येक पंक्ति को हटाए जाने पर पहचान कॉलम को पुनर्निर्मित करने की तुलना में किसी अन्य विधि का उपयोग करके हल किया जाएगा।

यह कहना मुश्किल है कि आपके आवेदन की आवश्यकता क्यों है, लेकिन यह तथ्य कि आपके एप्लिकेशन को इस कार्यक्षमता की आवश्यकता क्यों है, शायद यह कहीं भी किसी समस्या की समस्या का संकेत है।

Answer 7

आईडी पंक्ति के अद्वितीय पहचानकर्ता है।

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

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

Answer 8

मैंने एक बहु-स्तर के बिक्री कार्यक्रम को संभालने के लिए एक आवेदन लिखा था। बेशक, लोग बाहर निकलते हैं। हमारे में, लोगों को भी डालना पड़ा था।

आप एक संशोधन के साथ सही रास्ते पर हैं।

पहचान संख्या (आईडी) और अनुक्रम संख्या (सीईसी) दो अलग-अलग चीजें हैं। उनके साथ एक दूसरे के साथ कोई संबंध नहीं है।

कोई आईडी कभी नहीं बदलें। एक बार असाइन किया गया, हमेशा असाइन किया गया।

अनुक्रम के लिए अपनी तालिका में एक कॉलम (सीएनएक्सटी) बनाएं और इसे आईडी के साथ पॉप्युलेट करें। "इस अनुक्रम में अगला आईडी क्या है?"

सीएनएक्सटी में आईडी को घुमाएं, सीएनईएक्सटी को पुन: असाइन करें, जब भी आप चाहें। कोई संग्रहित प्रो ऐसा कर सकती है।

फिर आपके पास आईडी की अनुक्रमिक श्रृंखला बनाने के लिए लचीलापन भी है। यह उपयोगी होता है जब लोग विभिन्न क्षेत्रों पर जाते हैं या विभिन्न समूहों में प्रचार प्राप्त करते हैं।

आशा है कि इससे मदद मिलती है! :)

Answer 9

एक मिनट की Google खोज ने मुझे एक पृष्ठ दिया जो मैं प्रदर्शित नहीं कर सकता। Google यह और यह 6/1/2009 के रूप में आपका पहला लिंक होगा: tsql फिक्स "पहचान कॉलम"

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

यदि आपकी संपर्क तालिका आपकी केवल तालिका है या इस आईडी फ़ील्ड के आधार पर शून्य संबंध हैं, तो आप पहचान संपत्ति को NO पर सेट कर सकते हैं, मानों को 1 से COUNT (आईडी) में रेखांकित कर सकते हैं, फिर पहचान संपत्ति को YES पर सेट कर सकते हैं, TableID

बी सी सी CHECKIDENT ('TableID', reseed, @MaxID) से

घोषित @MaxID INT

चयन @MaxID = COUNT (आईडी): और का उपयोग कर पूरा करने के लिए पहचान reseed इस परिदृश्य में, आप कर सकते थे हटाए जाने के प्रत्येक सेट के बाद उपर्युक्त संशोधित स्क्रिप्ट का उपयोग करें (लेकिन प्रारंभिक रूप से प्रारंभ होने और सही ढंग से सेट होने के बाद COUNT (आईडी) से MAX (आईडी) को बदलें, यह तालिका को बड़ा होने पर थोड़ा गति जोड़ती है), किसी भी अतिरिक्त आवेषण या विदेशी से पहले मुख्य बाधा अद्यतन। सुनिश्चित करें कि आप हटाए गए ब्लॉक और रेडिंग ब्लॉक के चारों ओर लिपटे ट्रांज़ेक्शन का उपयोग करते हैं, और सुनिश्चित करें कि तालिका केवल सिंक्रोनस लेनदेन की अनुमति देती है, इससे अनुसंधान के बीच में किसी भी डेटा को खोने से रोका जा सकेगा।

जटिल ईएच? यही कारण है कि दाहिने पैर पर शुरू करना सबसे अच्छा है। ;) (मैंने अनुभव से यह सीखा है) यदि आपके कोई और प्रश्न हैं तो मुझे मैरोन एट याहू डॉट कॉम पर ईमेल करें।

Answer 10

सभी उत्तरों यह मान रहे हैं कि यह एक उत्पादन वातावरण है। अपने एक डेटाबेस डिजाइन का परीक्षण है, तो जल्दी से सभी तालिकाओं काटना चाहते हैं एक आसान तरीका यह पूरा करने के होना चाहिए:

बी सी सी CHECKIDENT ({तालिका नाम},, reseed 0)

* से सभी पंक्तियां हटाएं आईडी का उपयोग कर सभी टेबल पहले