क्या एक सरोगेट कुंजी को कभी किसी उपयोगकर्ता के सामने लाया जाना चाहिए?

14

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

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

सरोगेट कुंजी को उजागर करने का मुख्य लाभ आपके पास वैसे भी एक क्षेत्र का उपयोग करने की सादगी है।

किन परिस्थितियों में उपयोगकर्ताओं के लिए सरोगेट कुंजी को सीधे उजागर करना बेहतर है?

— psr
स्रोत

इस सवाल का एक हिस्सा यह है कि आपको 'उपयोगकर्ताओं' को परिभाषित करने की आवश्यकता है। उपयोगकर्ता एक ऐसे API के उपभोक्ता हो सकते हैं जिन्हें आप मांसल या निष्कासित करते हैं। दोनों के लिए जवाब एक जैसा नहीं होने वाला है।

— जेम्स स्नेल

1

मांसल इंसान।

— Psr

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

10

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

यदि डेटा में कोई प्राकृतिक व्यवसाय कुंजी नहीं है, तो आप "व्यवसाय पहचानकर्ता" के लिए एक अतिरिक्त फ़ील्ड जोड़ सकते हैं। इसे उन प्रक्रियाओं के लिए अनुकूलित किया जाना चाहिए जिनके लिए इसका उपयोग किया जाता है। टेलीफोन कीपैड प्रविष्टि का मतलब केवल संख्यात्मक है। फोन / वर्बल का अर्थ है कि समान ध्वनि वाले प्रतीकों (B / D, M / N, आदि) से बचें। तुम भी कुछ आसानी से यादगार वाक्यांश ("हरी जेली") autogenerate कर सकते हैं।

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

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

एक साइड नोट के रूप में, जब मैं यहां "एक्सपोज़िंग" कहता हूं, तो मेरा मतलब उपयोगकर्ता को इस उम्मीद के साथ कुंजी देना है कि वे इसे सीधे उपयोग करते हैं (जैसे कि अपने ऑर्डर नंबर के साथ समर्थन करने के लिए कॉल करना)।

— क्रिस पिटमैन
स्रोत

5

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

— रॉबर्ट हार्वे

1

नेवर से नेवर। क्या होगा अगर बाद के डिजाइन रिकॉर्ड समेकन की ओर जाता है? क्या होगा अगर आपको पहचान से दूर रखने और बदलने की जरूरत है?

— डगएम

3

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

— रॉबर्ट हार्वे

2

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

— क्रिस पिटमैन

2

@sqlvogel: अगर मैं "सरोगेट" के बजाय "सिस्टम-जनरेटेड प्राइमरी की" शब्द का इस्तेमाल करता हूं तो क्या यह स्पष्ट हो जाएगा? मैं इस बात से सहमत हूं कि आप उस एल्गोरिथ्म को बदलना चाहते हैं जो सरोगेट कुंजी उत्पन्न करता है, लेकिन यह उनके मौलिक रूप से अपरिवर्तनीय गुणवत्ता को नहीं बदलता है।

— रॉबर्ट हार्वे

4

कुछ मामलों में, सरोगेट कुंजियाँ अपेक्षित हैं और उपयोगकर्ताओं के लिए समझ में आती हैं। मेरा पसंदीदा उदाहरण "ऑर्डर नंबर" है। ऑर्डर नंबर वास्तव में एक प्राकृतिक कुंजी नहीं है: एक प्राकृतिक कुंजी टाइमस्टैम्प प्लस उपयोगकर्ता हो सकती है, या शायद उससे अधिक हो सकती है यदि आप उपयोगकर्ताओं से अपेक्षा करते हैं कि वे आपके टाइमस्टैम्प की ग्रैन्युलैरिटी के भीतर एक से अधिक ऑर्डर उत्पन्न करें।

फिर भी, उपयोगकर्ता ऑर्डर नंबर की सुविधा को समझते हैं और उसकी अपेक्षा करते हैं। कोई नुकसान नहीं है, और बहुत सारे मूल्य हैं, यदि आप उपयोगकर्ताओं को उनके बारे में बताते हैं।

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

— एलन शटको
स्रोत

यदि कोई उपयोगकर्ता इसे समझता है और इसके साथ बातचीत करने की अपेक्षा करता है, तो यह अब सरोगेट कुंजी नहीं है। सरोगेट कीज़ को व्यवसायिक अर्थ के रूप में परिभाषित किया गया है। सिर्फ इसलिए कि यह एक आईडी नंबर है जरूरी नहीं कि यह एक सरोगेट है। इसके अलावा, "कुछ सरोगेट कुंजी जो मुझे मेरे सदस्य आईडी, जन्म तिथि के आधार पर पहचानती है [...]" का कोई मतलब नहीं है। आप कह रहे हैं कि उनकी सरोगेट कुंजी (जिसका कोई व्यावसायिक अर्थ नहीं है) आपको उन चीजों के आधार पर पहचानती है जो एक प्राकृतिक कुंजी की रचना कर सकती हैं?

— काइल मैकवे

अक्सर, क्या होता है कि आपको एक कर्मचारी आईडी नंबर दिया जाता है ताकि कर्मचारी प्रणाली में आपको उसी नाम के अन्य लोगों से अलग किया जा सके। आपके बीमा कार्ड पर, यह आपकी कंपनी और कर्मचारी आईडी को सूचीबद्ध कर सकता है। लेकिन स्वास्थ्य बीमा कंपनी अक्सर अपनी स्वयं की आंतरिक आईडी उत्पन्न करती है जिसे वह अपने नियोक्ता से प्राप्त होने वाले नाम, जन्म तिथि और कर्मचारी आईडी का उपयोग करने के बजाय अपने सभी प्रणालियों में उपयोग कर सकती है। क्या ये उत्पन्न कुंजियाँ सरोगेट या प्राकृतिक कुंजी हैं? निर्भर करता है कि आप किससे पूछते हैं ( en.wikipedia.org/wiki/Surrogate_key पर 2 वैकल्पिक परिभाषा जांचें )

— एलन शटको

1

यदि यह ठीक से जेनरेट किया गया GUID / UUID * है तो आपको केवल एक सरोगेट कुंजी का पर्दाफाश करना चाहिए। OWASP टॉप 10 सुरक्षा मुद्दों पर अनुक्रमिक सरोगेट कुंजी का एक्सपोजिंग नंबर 4 है ।

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

— पीटर टेलर
स्रोत

2

यह आपके जवाब से स्पष्ट नहीं है कि कैसे एक GUID सुरक्षा में सुधार करता है।

— रॉबर्ट हार्वे

1

@RobertHarvey - मुझे लगता है क्योंकि वे अनुक्रमिक नहीं हैं और इसलिए अनुमान नहीं लगाया जा सकता है।

— बोबसन

1

security.stackexchange.com/q/38777

— रॉबर्ट हार्वे

@ रोबर्टहेयर, ने स्पष्ट किया।

— पीटर टेलर

1

यदि किसी तालिका में कोई प्राकृतिक कुंजी नहीं है, तो सरोगेट कुंजी इस तरह पंक्तियों को अनुमति देती है।

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

मैं सरोगेट कुंजियों के बजाय इन कृत्रिम कुंजियों को कॉल करूंगा, लेकिन इस प्रश्न के लिए यह अंतर महत्वपूर्ण नहीं है।

अब, यह मानते हुए कि विदेशी कुंजियों के माध्यम से इन सरोगेट कुंजी को संदर्भित करने वाला महत्वपूर्ण डेटा है, अंत उपयोगकर्ताओं को यह कैसे पता चलेगा कि अगर वे सरोगेट प्रमुख मूल्यों को नहीं जानते हैं तो उन्हें किस पंक्ति को अपडेट करना है ?

— माइक शेरिल 'कैट रिकॉल'
स्रोत

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

— काइल मैकवे

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

— माइक शेरिल 'कैट रिकॉल'

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

— काइल मैकवे

0

आम आदमी के शब्दों में:

सरोगेट्स को उपयोगकर्ता से छिपाया जाना चाहिए।
आपको उपयोगकर्ता के लिए कुछ अन्य व्यावसायिक उम्मीदवार को उजागर करना चाहिए।
यदि कोई अन्य उम्मीदवार कुंजी मौजूद नहीं है, तो आपको पीके दिखाना चाहिए। लेकिन इस मामले में पीके को सरोगेट नहीं माना जाता क्योंकि यह अन्य कॉलम का विकल्प नहीं है।

— ट्यूलेंस कोर्डोवा
स्रोत

पीके को क्यों दिखाया जाना चाहिए? मुझे लगता है कि यह मेरा सवाल है - क्या पीके को एक ऑटो जेनरेट किया गया है जिसे सरोगेट कुंजी कहा जाता है।

— Psr

1

@psr आपका प्रश्न शीर्षक " सरोगेट कुंजी कभी उजागर हो " कहता है । मैंने कहा नहीं। लेकिन आपको कोई और चाबी दिखानी होगी। यदि कोई अन्य कुंजी मौजूद नहीं है, तो आपके पास एकमात्र कुंजी होनी चाहिए। स्पष्ट रूप से मैं स्पष्ट करता हूं कि उन मामलों में कुंजी वास्तव में सरोगेट नहीं है क्योंकि यह किसी अन्य कॉलम का विकल्प नहीं है।

— ट्यूलेंस कोर्डोवा

सवाल यह है कि क्या आपको एक कॉलम जोड़ना चाहिए, या आपके पास मौजूद कुंजी दिखाना चाहिए।

— psr

@psr मैंने इसे और अधिक स्पष्ट करने के लिए अपना उत्तर फिर से दिया।

— ट्यूलेंस कोर्डोवा

1

मुझे लगता है कि भौतिक रूप से नगण्य भेद होना चाहिए। यदि आपका नियम यह है कि प्रत्येक तालिका में एक कृत्रिम कुंजी है (जो मेरी है), और केवल कृत्रिम कुंजी जुड़ती है (जो कि मेरा सिद्धांत भी है) में भाग लेते हैं, तो यह धारणा है कि एक कुंजी एक सरोगेट है क्योंकि अन्य कुंजी संभवतः हो सकती हैं उपलब्ध नहीं है।

— रॉबर्ट हार्वे

0

आपको केवल एक उपयोगकर्ता के लिए एक फ़ील्ड को उजागर करना चाहिए जो उपयोगकर्ता को उपयोगी जानकारी प्रदान करता है, या तो सीधे या रिपोर्टिंग दोषों में।

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

— DougM
स्रोत

0

इससे कोई फर्क नहीं पड़ता कि आप कुंजियों को उजागर करते हैं या अंत उपयोगकर्ता को नहीं। आपके आवेदन को आवश्यक प्राधिकरण करना चाहिए, जैसे कि केवल एक ऑर्डर आईडी जानना, उदाहरण के लिए, उन्हें कुछ ऐसी चीज़ों तक पहुंच की अनुमति नहीं दे सकता है जो वे आमतौर पर उपयोग नहीं कर सकते हैं।

चेतावनी: यह एक वेब आधारित या n- स्तरीय अनुप्रयोग मानता है जहाँ सर्वर साइड प्राधिकरण संभव / संभव है। यदि आपके पास एक VB ऐप है जो सीधे sql को निष्पादित करता है, तो एक संपूर्ण 'nother समस्या' है।

— GrandmasterB
स्रोत

विदेशी कुंजी रिश्तों को संरक्षित करते हुए, रिकॉर्ड्स को हटाने में सक्षम नहीं होने के बारे में क्या, जैसा कि सवाल में बताया गया है?

— Psr

उपयोगकर्ता की कुंजी को उजागर करने के साथ क्या करना है? हो सकता है कि मैं 'एक्सपोज़िंग' शब्द के आपके उपयोग को न समझूँ। मैं इस धारणा से काम कर रहा हूं कि आप 'उपयोगकर्ता द्वारा देखा जा सकने में सक्षम' हैं।

— ग्रैंडमास्टरबी