नकारात्मक प्राथमिक कुंजी

Question

क्या तालिकाओं के लिए नकारात्मक प्राथमिक कुंजी (पहचान वृद्धि -1, एसक्यूएल सर्वर 2005 में पहचान बीज -1) का उपयोग कर कोई प्रतिक्रिया है?

इसका कारण यह है कि हम मौजूदा को बदलने के लिए एक नया डेटाबेस बना रहे हैं। दो डेटाबेस के बीच समान सारणीएं हैं और हम जानकारी के "स्रोत" को हमारे अनुप्रयोगों के लिए पारदर्शी होना चाहते हैं। दृष्टिकोण यह है कि दोनों डेटाबेसों से यूनियन टेबल देखें। नकारात्मक पीके सुनिश्चित करता है कि पहचान ओवरलैप नहीं होती है।

Answer 1

दूसरों की तरह कहा है, डेटाबेस इसके साथ ठीक है।

लेकिन यह .NET अनुप्रयोग के लिए एक समस्या होगी जो डेटासेट + डेटा एडाप्टर का उपयोग करता है क्योंकि वे नए रिकॉर्ड के लिए अस्थायी कुंजी के रूप में नकारात्मक कुंजी का उपयोग करते हैं।

अन्य डेटा-एक्सेस परतें समान चाल का उपयोग कर सकती हैं।

Answer 2

कोई समस्या नहीं है।

यह थोड़ा गैर रूढ़िवादी है, लेकिन इसके अलावा, ठीक है।

एसक्यूएल सर्वर द्वारा दी गई डिफ़ॉल्ट केवल यही है - एक डिफ़ॉल्ट, और सूट आवश्यकताओं के लिए बदला जा सकता है। ऐसा लगता है कि आपको एक अच्छा समझौता हुआ है।

Answer 3

यह SQL सर्वर के परिप्रेक्ष्य से बिल्कुल ठीक है। असली सवाल आपका आवेदन होगा।

Answer 4

केवल समस्या यह है कि आप इस तरह तीसरे डेटा स्रोत को जोड़ने में सक्षम नहीं होंगे!

Answer 5

यह कोई मुद्दा नहीं है। बस सुनिश्चित करें कि आपका पहचान कॉलम एक प्रकार का है जो नकारात्मक संख्याओं की अनुमति देता है।

Answer 6

आप विरासत कोड की समीक्षा करना चाहते हैं और देख सकते हैं कि डेवलपर्स ने प्राथमिक कुंजी पर तिथि के अनुसार सॉर्ट करने के आलसी/मैला तरीके के रूप में सॉर्ट किया है (क्योंकि पहचान पीके आमतौर पर समय से दृढ़ता से या पूरी तरह से संबंधित हैं)।

Answer 7

यदि नकारात्मक संख्या कुछ तोड़ने के लिए बाहर निकलती है, तो दूसरे के लिए एक और विषम संख्याओं के लिए भी संख्याओं का उपयोग करें।

Answer 8

एक और विकल्प विरासत कुंजी को "OLD_" जैसी स्ट्रिंग के साथ उपसर्ग करना है। ओनी समस्या यह है कि आपका मुख्य क्षेत्र गैर-संख्यात्मक होगा।

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

Answer 9

मुझे लगता है कि तकनीकी रूप से अनुमति के दौरान, 2 स्रोतों को इस दृष्टिकोण के लिए सही कारण नहीं है। यह स्केलेबल नहीं है (इसके लिए लैरी लुस्टिग का जवाब +1)।

मैं केवल एक दृश्य या संग्रहीत प्रक्रिया तैयार करता हूं जो आईडी को परिवर्तित करने के लिए दोनों डेटा को जोड़ता है, और सीधे तालिका पढ़ने और यूनियनों के बजाय इसका उपयोग करने के लिए आवेदन होगा। एक और स्रोत जोड़ने के लिए बाद में दृश्य/एसपी को संशोधित करके यह मापनीय होगा।