कुछ तालिकाओं के लिए डेटाबेस में एक द्वितीयक प्राथमिक कुंजी बनाना

Question

अपनी कुछ तालिकाओं के लिए मैं "second_primary_key" जोड़ना चाहता हूं जो uuid या कुछ यादृच्छिक लंबी कुंजी होगी। मुझे इसकी आवश्यकता है क्योंकि कुछ तालिकाओं के लिए मैं पूर्णांक को अपने वेब अनुप्रयोग में उजागर नहीं करना चाहता। यही है, एक पृष्ठ "/ चालान" पर मेरे पास चालान की एक सूची है और "/ चालान /: आईडी" के लिए एक लिंक है जहां: आईडी एक पूर्णांक है। मैं नहीं चाहता कि कोई उपयोगकर्ता यह जाने कि मेरे सिस्टम में कितने इनवॉइस हैं, इसलिए "/ इनवॉइस / 123" के बजाय मैं इसके "सेकंड_प्रिमरी_की" का उपयोग करना चाहता हूं ताकि url "/ चालान / N8Zk241vNa" हो जाए

वही अन्य तालिकाओं के लिए जाता है जहां मैं असली आईडी छिपाना चाहता हूं।

मुझे आश्चर्य है, क्या यह एक आम बात है? इसे लागू करने का सबसे अच्छा तरीका क्या है?

और इस तकनीक को आखिर क्या कहा जाता है, ताकि मैं इस पर खोज करूं?

Comments

पूर्णांक से छुटकारा क्यों नहीं मिलता है?

— लार्सबे

आप किसी तालिका पर अपनी पसंद के अनुसार कई विशिष्ट कुंजी / अनुक्रमित परिभाषित कर सकते हैं।

— अबुजितिन गिलिफ़िर्का

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

— वाल्टर किटी

"दूसरा प्राथमिक" एक ऑक्सीमोरोन है। आपके पास एक प्राथमिक कुंजी है, और आपके पास द्वितीयक कुंजी हो सकती है।

— मोनिका

@RobbieDee डेटाबेस को पूरी तरह से सामान्यीकृत नहीं करने के लिए वैध कारण हैं। और एक उम्मीदवार या माध्यमिक कुंजी होने से डेटा की नकल नहीं होती है।

— मचाडो

Answer 1

आप एक UUID कॉलम जोड़ सकते हैं, लेकिन आपको वास्तव में (और ऐसा नहीं करना चाहिए) नहीं है। यह एक प्रस्तुति परत चिंता है। आप कहने का सपना नहीं देखेंगे, 1999 के रूप में $ 1,999 के रूप में एक मुद्रा मूल्य का भंडारण।

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

चूंकि हम केवल एक ही मूल्य के बारे में बात कर रहे हैं, हो सकता है कि एईएस या समान जैसे 2 तरह के एन्क्रिप्शन को देखें - अधिक हल्का बेहतर।

हैशिंग एक और संभावना हो सकती है - यह इस बात पर निर्भर करता है कि क्या आप चालान नंबर वापस लेना चाहते हैं, क्योंकि हैशिंग एक रास्ता है।

Answer 2

"वैकल्पिक प्राथमिक कुंजी" होने से संबंधपरक डेटाबेस मॉडलिंग में एक अच्छी तरह से ज्ञात अवधारणा है, इसे "वैकल्पिक कुंजी" कहा जाता है, या कभी-कभी "माध्यमिक कुंजी" भी कहा जाता है। "संभावित प्राथमिक कुंजी" के सेट को "उम्मीदवार कुंजी" कहा जाता है। Https://beginnersbook.com/2015/04/alternate-key-in-dbms/ देखें

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

Comments

मैंने इस परिदृश्य का वर्णन करने के लिए उपयोग की जाने वाली प्राकृतिक कुंजी बनाम सरोगेट कुंजी भी देखी है।

— डंके

@ दारी: आपने पूछा "इस तकनीक को क्या कहा जाता है" - बोल्ड अक्षरों में। और अगर एईएस डिक्रिप्शन - हो सकता है कि मक्खी पर - आप जिस तरह की तलाश कर रहे हैं, उसकी कुंजी पैदा करता है, इसका उपयोग करें, जो आपके उत्तर का खंडन नहीं करता है।

— डॉक्टर ब्राउन

@ डारी क्योंकि यह आपके ऐप में पूरी तरह से अनावश्यक ओवरहेड जोड़ता है

— लैमैक

@RobbieDee हमें पहले ही मिल गया है कि आपको वैकल्पिक कुंजी पसंद नहीं है, लेकिन इसका मतलब यह नहीं है कि वे बेकार हैं। मुझे गाइड दृष्टिकोण पसंद है क्योंकि यह बहुत सारी समस्याओं को सरल करता है।

— टी। सर -

@RobbieDee हम SQL सर्वर का उपयोग नहीं करते हैं। हम MySql का उपयोग करते हैं। और ऐसा इसलिए होता है क्योंकि कोई व्यक्ति प्रोडक्ट पर कुछ बनाएगा, आइए आइडी 1234 के साथ कहें। देव पर, स्वाभाविक रूप से, हम कई और संस्थाएं बनाते हैं, जो हम ठेस से करते हैं। 1234 को परीक्षण के लिए कुछ फेंक इकाई द्वारा बहुत पहले लिया गया था। जब हमें ठेस से किसी इकाई का परीक्षण करना होता है, तो हमें इसे देव में वापस भेजना होगा - और इसकी प्राथमिक कुंजी पहले से ही उपयोग में है। माइग्रेशन बहुत आसान है यदि उस इकाई के संदर्भ गाइड आधारित हैं। लेकिन हाइबरनेट एक प्राथमिक कुंजी इंट या लंबे होने के साथ बेहतर काम करता है, इसलिए हम इसे बनाए रखते हैं। मेरे देव आलसी या अज्ञानी नहीं हैं - वे अनुभवी हैं।

— corsiKa

Answer 3

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

एक उपयोगकर्ता चालान संख्या से कटौती कर सकता है कि आपने कितने ग्राहकों की सेवा की है, या चालान पर नंबरिंग रणनीति को बदलने से पहले यह कितनी देर तक था।

डेटाबेस में कितने इनवॉइस संग्रहीत किए जाते हैं, आपके इनवॉइस के भव्य कुल का कोई माप नहीं है। चैंबर ऑफ कॉमर्स से अपनी साल की रिपोर्ट का अनुरोध करने सहित, यह पता लगाने के अन्य साधन हैं।

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

Comments

बैंकिंग में उपयोग की जाने वाली एक सामान्य रणनीति (चेक संख्या के साथ) 1 पर वृद्धिशील गणना शुरू नहीं करना है, बल्कि इस सटीक कारण के लिए कुछ बड़ी संख्या है।

— डंके

मुझे लगता है कि आईडी को एक अतिरिक्त प्राथमिक कुंजी होना चाहिए, पुरानी प्राथमिक कुंजी के प्रतिस्थापन के लिए नहीं।

— अलेक्जेंडर

मैं इसे प्राथमिक कुंजी नहीं कहूंगा। मैं एक स्लग के लिए जाना चाहता हूं, नाम के रूप में एक यूयूआईडी, लेकिन संक्षेप में यह तालिका में सिर्फ एक और अनुक्रमित क्षेत्र है। उद्धरण आईडी, चालान संख्या, जो भी हो। यह एक फ़ील्ड है, लेकिन प्राथमिक कुंजी नहीं है। एक प्राथमिक कुंजी को अद्वितीय होने की आवश्यकता है, और आंतरिक रूप से रिलेशनल मैपिंग के लिए उपयोग किया जा सकता है। यदि अनुक्रमित फ़ील्ड को एक क्वेरी के द्वारा जल्दी से खोजा जा सकता है। userXveryY.where ( 'INVOICE_NUMBER', 'foobarbaz10') मिलता है ()।;

— 13

आप एक तकनीकी प्रश्न का उत्तर इस तर्क के साथ दे रहे हैं कि इसकी आवश्यकता यूएसए की ख़ासियतों (अनुक्रमिक चालान संख्या की आवश्यकता के कारण नहीं है, चैंबर ऑफ़ कॉमर्स में रिपोर्ट)। IMO इस प्रश्न का उत्तर अच्छी तरह से नहीं देता है।

— रेमकोगर्लिच

Answer 4

आप इसके लिए हैशिड्स का उपयोग करने में सक्षम हो सकते हैं , यह बिल्कुल इस परिदृश्य को हल करने के लिए डिज़ाइन किया गया है।

यह आपकी डेटाबेस आईडी को एक छोटी हैश (YouTube वीडियो के URL के समान) में एन्कोड करेगा, और इसके लिए आपको अपनी तालिका में कोई भी द्वितीयक कुंजी जोड़ने की आवश्यकता नहीं होगी।

Comments

नाम कुछ भ्रामक है, क्योंकि यह हैश नहीं है, लेकिन प्रतिवर्ती कार्य है। लेकिन यह समस्या का सही समाधान प्रतीत होता है।

— क्रेजी योगर्ट 13

@CrazyYoghurt यह सच है ... उन्होंने इसका नामकरण करने का कारण बताया जैसा कि उन्होंने यहां किया: hashids.org/#why-hashids

— Eric King

Answer 5

आप एक और अनूठी कुंजी बना सकते हैं, लेकिन आपको नहीं करना चाहिए। दिए गए कारण के लिए नहीं। टेबल के आकार को छिपाने के सरल तरीके हैं।

भंडारण की N_8Zk241vNaलागत तालिका में प्रति पंक्ति 12 बाइट और सूचकांक में और भी अधिक है। आप की जरूरत है कि बहुत बेकार है।

पूर्णांक को एन्क्रिप्ट idकरने से आपके पास कोई स्थान नहीं है और रन समय में कुछ भी नहीं है। आप इसे कैसे करते हैं यह आपकी प्रोग्रामिंग भाषा और / या आपके डेटाबेस पर निर्भर करता है।

ध्यान दें कि एईएस के साथ आपको 128 बिट पूर्णांक मिलता है, जिसका अर्थ है कि बेस 64 में 22 वर्ण, संभवतः आप जितना चाहते हैं उससे अधिक। 64 के ब्लॉक साइज जैसे DES या 3DES के साथ एक सिफर आपको 11 अक्षर देता है, जैसे आप चाहते हैं।

विभिन्न तालिकाओं के लिए विभिन्न कुंजियों का उपयोग करें।

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

Comments

वास्तव में - इस मान को दूसरे को छिपाने के लिए संग्रहीत करना सिर्फ गलत है।

— रोबी डी

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

— डंके

मैं यहां एसेस कैसे लगा सकता हूं?

— डारी

@ डारी आप एईएस को किसी भी चीज पर कैसे लागू कर सकते हैं ? आपकी भाषा जाने बिना कोई नहीं बता सकता। आमतौर पर, एईएस एक के साथ काम करता है byte[], आप अपने idचार या आठ बाइट्स में लिख सकते हैं , एक अद्वितीय तालिका संख्या और एन्क्रिप्ट (इनपुट बिल्कुल 16 बाइट्स होना चाहिए) जोड़ें। यदि चुनने के तरीके हैं, तो ईसीबी सही है।

— Maaartinus

@DANK क्या? क्या आप दावा कर रहे हैं कि एईएस असुरक्षित है? कुंजी को जानने के बिना, कुछ भी नहीं है हमलावर किसी भी संग्रहीत विशेषता के लिए बेहतर कर सकता है। कुछ भी तो नहीं। +++ मुझे लगता है, मैं आपकी टिप्पणी नहीं समझ रहा हूँ।

— Maaartinus

Answer 6

दो अलग-अलग प्राथमिक कुंजी बनाने वाला IMHO संभव नहीं है। निश्चित रूप से आप उस uuid को DB में डाल सकते हैं ताकि उसे वर्तमान प्राथमिक कुंजी के लिए "उपनाम" के रूप में रखा जा सके। आप अद्वितीय बाधा के साथ उस कॉलम के ऊपर एक इंडेक्स डाल सकते हैं, लेकिन प्राथमिक कुंजी (इसके सार से) सिंगल टेबल के भीतर एक है। समग्र प्राथमिक कुंजी हो सकती है, लेकिन यह वह नहीं है जो आप खोज रहे हैं।

इसलिए मैं इसे वहां लगाने का सुझाव देता हूं, लेकिन यह केवल सूचकांक के साथ है। आप PK और साथ ही अन्य अनूठे कॉलम द्वारा डेटा की क्वेरी के लिए हैंडलिंग घटक बना सकते हैं। जब "/ चालान / ..." के लिए अनुरोध को संभालते हुए बस पैरामीटर की जांच करें - यदि यह पूर्णांक है, तो आईडी खोजें, अन्यथा यूआईडी खोजें। या जब आप आईडी खोज में कुछ भी नहीं मिला, तो आप एक खोज के रूप में uuid खोज कर सकते हैं।

और कुछ "बेतरतीब" uuids उत्पन्न करने के बारे में: क्यों नहीं "ID ले लो, CONSTANT जोड़ें, हेक्साडेसिमल में परिवर्तित करें" जैसे कुछ। आईडी की विशिष्टता यूआईडी की विशिष्टता प्रदान करेगी, हेक्साडेसिमल संख्या सामान्य मोर्टल्स के लिए पढ़ने के लिए कठिन है + निरंतर जोड़ने से यूआरआईडी जैसे 00000001 होने से बच जाएगा।

Comments

"क्यों नहीं कुछ" जैसे आईडी लेते हैं, CONSTANT जोड़ते हैं, हेक्साडेसिमल में कनवर्ट करते हैं "- क्योंकि यह पता लगाना बहुत आसान है - मुझे एक URL दें और मुझे सिस्टम के अन्य सभी चालानों पर एक नज़र होगी। IMO कोई समस्या नहीं है। यह वास्तव में हल करता है, बस इसे संभावित रूप से बनाता है।

— CompuChip

" जब /" चालान / ... "के लिए अनुरोध को संभालते हुए, बस पैरामीटर की जांच करें - यदि यह पूर्णांक है, तो आईडी खोजें , अन्यथा uuid खोजें " पूरे बिंदु (जैसा कि मैं प्रश्न समझता हूं) किसी को आईडी द्वारा खोज को रोकने के लिए है ( /invoices/123, /invoices/124, ...) तो आप केवल URL से UUID द्वारा खोज करेंगे।

— ट्रीपहाउंड

इसके अलावा, सभी हेक्साडेसिमल संख्याओं में अक्षर नहीं होते हैं। यह हमेशा आपके अंतर्निहित पूर्णांक और आपके उत्पन्न हेक्स संख्या के बीच अंतर करना असंभव होगा।

— TRGG

@CompuChip जैसा कि मुझे उम्मीद है, आप कंप्यूटर में रुचि रखते हैं :-) ताकि आप पहली नजर में हेक्स संख्या को पहचान सकें। लेकिन Q को इस तरीके से लिखा गया था कि चालान नंबर सीधे न दिखाए ताकि दूसरों को पता चल सके कि कितने चालान हैं। जब मैं अपनी पत्नी, माँ, पड़ोसी को कुछ हेक्स संख्या दिखाता हूं ... तो उन्हें पता नहीं चलेगा कि "अजीब पाठ" क्या है। यदि Q के भीतर चालान संख्या के अनुसार सुरक्षा समस्या के बारे में सूचना होगी, तो मैं उस उद्देश्य के लिए कुछ जटिल हैशिंग विधि सुझाऊंगा।

— जर्दा

@ ट्राइपाउंड वह अभी भी आंतरिक रूप से या कुछ एक्सेस-प्रतिबंधित प्रवेश बिंदु के भीतर आईडी द्वारा खोज करने में सक्षम हो सकता है ...

— जर्दा

Answer 7

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

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

मेरी समझ के अनुसार, चाबियाँ अंतर्निहित सूचक हैं, और जितना अधिक आप सूचकांक जोड़ते हैं, उतना ही धीमी आवेषण होगा।

Comments

+1 याप, जो कि संभावित रूप से एक इंडेक्स के साथ एक बड़ा स्ट्रिंग कॉलम है, निश्चित रूप से अन्य लोगों के सुझाव के मूल्य मुक्त संचालन नहीं है। स्टोरेज ओवरहेड एक तरफ, जैसे ही इंडेक्स जुड़ते हैं, सम्मिलन की गति कम होने लगती है।

— रॉबी डी

Answer 8

आपके विशेष उपयोग के मामले में एक और तरीका यह है कि डेटाबेस और एप्लिकेशन को संशोधित करने के बजाय, आप बस चालान का एक कस्टम मार्ग बना सकते हैं, इसलिए / चालान /: f (आईडी) जहां f (आईडी) आईडी का कुछ कार्य है।

कस्टम मार्ग सही एक्शन सर्वर-साइड के लिए अनुरोध करने के लिए जिम्मेदार है।

Answer 9

यह पूरी तरह से स्वीकार्य अभ्यास है, जिसे 'अल्टरनेटिव की' (एके) भी कहा जाता है। मूल रूप से AK एक और विशिष्ट सूचकांक या अद्वितीय अवरोध है।

तुम भी अपने एके के आधार पर विदेशी कुंजी बाधाओं बना सकते हैं।

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

Answer 10

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

चूंकि प्रश्न चालान और संख्याओं के संदर्भ में है, इसलिए यह शोध के लिए सार्थक हो सकता है कि लेखा उद्योग कैसे चालान संख्याओं को देखने की उम्मीद करता है: http://smallbusiness.chron.com/assign-invoice-numbers-52422.html

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

आदर्श रूप से आप पूरी कोशिश करते हैं कि चाबी / विदेशी कुंजियों पर तालिकाओं को एक साथ न बाँधें जो बदलने की संभावना है, और अपने आंतरिक तालिकाओं और संबंधों को ऐप परत पर पारदर्शी रखें।

Answer 11

इसका लाभ उठाएं।

यह एक "स्लग" क्षेत्र से भिन्न नहीं है जो ब्लॉग लेख और जैसे अक्सर होता है - प्राथमिक कुंजी से अलग डेटाबेस रिकॉर्ड को संदर्भित करने का एक अनूठा तरीका, एक URL में उपयोग के लिए फिट है। मैंने कभी किसी को उन लोगों के खिलाफ बहस करते नहीं सुना।