एक प्राथमिक कुंजी को उजागर क्यों नहीं किया

Question

मेरी शिक्षा में मुझे बताया गया है कि उपयोगकर्ता के लिए वास्तविक प्राथमिक कुंजी (न केवल डीबी कुंजी, बल्कि सभी प्राथमिक एक्सेसर्स) को उजागर करना एक त्रुटिपूर्ण विचार है।

मैंने हमेशा सोचा था कि यह एक सुरक्षा समस्या है (क्योंकि एक हमलावर अपने स्वयं के सामान को पढ़ने का प्रयास कर सकता है)।

अब मुझे जांचना होगा कि क्या उपयोगकर्ता को वैसे भी एक्सेस करने की अनुमति है, तो क्या इसके पीछे एक अलग कारण है?

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

---

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

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

गतिविधि बहुत बारीक है, इसलिए यह कुछ कंटेनर ऑब्जेक्ट में एक साथ है, इसे "टास्क" कहते हैं।

तीन usecases:

1. उपयोगकर्ता A उपयोगकर्ता B को कुछ कार्य में भेजना चाहता है, इसलिए वह उसे कुछ गतिविधि करने के लिए एक लिंक (HTTP) भेजता है।
2. उपयोगकर्ता B को भवन के बाहर जाना होता है इसलिए वह अपने मोबाइल डिवाइस पर कार्य खोलता है।
3. लेखांकन टास्क के लिए ग्राहक से शुल्क लेना चाहता है, लेकिन तीसरे पक्ष के लेखा प्रणाली का उपयोग करता है जो स्वतः ही कुछ कोड द्वारा कार्य / गतिविधि को लोड करता है जो REST को संदर्भित करता है - अनुप्रयोग का API

प्रत्येक usecases की आवश्यकता होती है (या आसान हो जाता है) यदि एजेंट के पास टास्क और गतिविधि के लिए कुछ पता योग्य पहचानकर्ता है।

Comments

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

— gnat

@gnat ON UPDATE CASCADEउस (mysql specific?) के लिए बनाया गया था, हालाँकि यदि समस्या सुरक्षा की है तो एक्सेस चेक बैकएंड पर होनी चाहिए और उपयोगकर्ता पर वैसे भी भरोसा नहीं करना चाहिए

— Izkata

@Izkata हाँ, सिवाय जब आप उन्हें एक अलग डेटास्टोर (एक साधारण उदाहरण के रूप में LDAP में उपयोगकर्ता) का संदर्भ देते हैं, या आपको बैकअप से कुछ डेटा पुनर्प्राप्त करने की आवश्यकता होती है। gnat का वहां एक अच्छा बिंदु है।

— एंजेलो फुच्स

क्या आप इसका खुलासा कर सकते हैं कि "एक्सपोज़" से आपका क्या मतलब है? एक वास्तविक उदाहरण मदद कर सकता है। :-)

— कोडकेस्टर

"एक्सपोज़" का अर्थ है उपयोगकर्ता को दिखाना। (उपयोगकर्ता से मेरा मतलब है एक मानव ज्यादातर, लेकिन सवाल मशीनों के लिए भी मान्य लगता है)

— एंजेलो फुच्स

Answer 1

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

ठीक ठीक। स्टेटलेस HTTP लें, जो अन्यथा यह नहीं जानता कि इसे किस संसाधन से अनुरोध करना चाहिए: यह 218306URL में आपके प्रश्न की आईडी को उजागर करता है । शायद आप वास्तव में सोच रहे हैं कि क्या एक उजागर पहचानकर्ता का अनुमान लगाया जा सकता है ?

केवल उन जगहों पर जहां मैंने एक नकारात्मक उत्तर सुना है, तर्क का उपयोग किया: "लेकिन वे URL में आईडी बदल सकते हैं!" । इसलिए उन्होंने उचित प्राधिकरण को लागू करने के बजाय GUID का उपयोग किया।

मैं एक ऐसी स्थिति की कल्पना कर सकता हूं जहां आप नहीं चाहते कि आपके पहचानकर्ता पूर्वानुमानित हों: संसाधन कटाई। यदि आपके पास एक ऐसी साइट है जो सार्वजनिक रूप से कुछ संसाधनों को होस्ट करती है, तो अन्य लोग दिलचस्प हो सकते हैं, और आप उन्हें ऐसे होस्ट करते हैं /images/n.jpgया /videos/n.mp4जहां nबस एक वेतन वृद्धि की संख्या है, जो आपकी वेबसाइट से और आपकी वेबसाइट पर आने वाले सभी ट्रैफ़िक को देख सकते हैं।

तो, अपने प्रश्न का सीधे उत्तर देने के लिए: नहीं, यह सीधे "उजागर" पहचानकर्ताओं के लिए बुरा नहीं है जो केवल आपके कार्यक्रम के लिए अर्थ रखते हैं, आमतौर पर आपके कार्यक्रम को सफलतापूर्वक संचालित करने के लिए भी इसकी आवश्यकता होती है।

Comments

अयोग्य यूरेल (उदाहरण के लिए क्रिप्टोग्राफिक रूप से यादृच्छिक 128 बिट टोकन) उचित प्राधिकरण का एक रूप हैं।

— कोडइन्चोसोस

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

— कोडकेस्टर

एचएम? जाहिर है कि इसके लिए एसएसएल की आवश्यकता होती है, लेकिन यह मामला है कि आप कैसे प्रमाणित और अधिकृत करते हैं। SSL पर एक हमलावर टोकन नहीं सीख सकता (ठीक उसी तरह जैसे वे कुकीज़ नहीं सीख सकते हैं) और यह रिप्ले हमलों को भी रोकता है। इस दृष्टिकोण का मुख्य नकारात्मक पक्ष यह है कि आप अलग-अलग उपयोगकर्ताओं के लिए पहुँच रद्द नहीं कर सकते, इसलिए मैं इसका उपयोग केवल अपरिवर्तनीय संसाधनों के लिए करना पसंद करता हूँ। अपरिवर्तनीय संसाधनों तक पहुंच को निरस्त करना अर्थहीन है क्योंकि एक हमलावर केवल एक स्थानीय कॉपी स्टोर कर सकता है।

— कोडइन्चोसोस

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

— कोडकस्टर

कोई नहीं, बिल्कुल मेरी बात। क्या आप शायद इसके बारे में विस्तार से बता सकते हैं कि "एक्सपोज़" का क्या मतलब है?

— कोडकास्टर

Answer 2

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

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

Comments

+1 लेकिन आप जो यहां बता रहे हैं वह वास्तव में एक सरोगेट कुंजी है। प्रत्येक तालिका में एक सरोगेट कुंजी नहीं होती है और भले ही वह सरोगेट "प्राथमिक" कुंजी न हो।

— nvogel

+1 मैंने सोचा था कि खाता संख्या सरोगेट कुंजी होगी, लेकिन मैंने इस पर पढ़ा और आप 100% सही हैं :)

— माइकल डुरंट

+1 उपयोगकर्ताओं के लिए इसे उजागर करने से निहित आवश्यकताएं (जैसे स्थिर रहें)

— मैट

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

— जिमीजैम

tl; dr: क्योंकि भविष्य। अगर किसी बाहरी चीज़ पर भरोसा करना आता है, तो कार्यान्वयन में बदलाव होने पर चीजें गड़बड़ हो जाती हैं; इसलिए चीजों को आसान बनाने के लिए उन्हें कम या ज्यादा छिपा कर रखें।

— एडम टॉली

Answer 3

क्योंकि प्राथमिक कुंजी एक कार्यान्वयन विवरण है।

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

Comments

एप्लिकेशन परत विशिष्ट रूप से एक प्राथमिक कुंजी के बिना डेटा लेयर में से पुनर्प्राप्त या अद्यतन करने के लिए इच्छित संसाधन की पहचान कैसे करेगी?

— कोडकेस्टर

@ कोडकोड - या तो डेटा के कुछ अनूठे अनुक्रमित सेट द्वारा, या एक गैर-सार्वजनिक प्राथमिक कुंजी द्वारा जो डेटा एक्सेस परत द्वारा आपूर्ति की गई वस्तु के हिस्से के रूप में वापस आ जाती है।

— तेलस्तीन

@ कोडकोड - एक टोकन बनाने के लिए बहुत सारे तरीके हैं जो कॉलबैक को यह निर्दिष्ट करने की अनुमति देता है कि क्या ऑपरेशन किया जा रहा है, और निश्चित रूप से उन सभी को प्राथमिक कुंजी सही माध्यम से पारित नहीं करना है।

— तेलस्टीन

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

— कोडकस्टर

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

— तेलस्टिन

Answer 4

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

आपको डेटाबेस प्राथमिक कुंजी को उजागर नहीं करना चाहिए, बल्कि एक सरोगेट कुंजी का उपयोग करना चाहिए

1. यदि आप चाहते हैं कि आपके उपयोगकर्ता कम से कम (कम से कम) याद रखें या किसी प्रविष्टि के पहचानकर्ता को पहचान सकें। ( ग्रेस्टोन 28 एस जवाब )
2. यदि आप आगे की योजना बनाना चाहते हैं और विचार करें कि आप सिस्टम (डेटाबेस या अन्यथा) को बदल सकते हैं जो संभवतः आपके पीके को बदल देगा। ( टेलस्टाइन उत्तर )
3. यदि आप यह सुनिश्चित करना चाहते हैं कि आपके उपयोगकर्ताओं के पास डेटा तक पहुँचने का एक सुसंगत तरीका है, भले ही आपकी कंपनी स्वामित्व बदल जाए और डेटा अलग-अलग सिस्टम में माइग्रेट हो जाए तो भी परिवर्तन नहीं होगा। ( माइकल डुरंट्स उत्तर )
4. यदि आपका पीके पूर्वानुमानित है (एक अनुक्रम की तरह) तो आपका सिस्टम संसाधन फसल की समस्याओं को झेल सकता है। ( कोडकैस्टर्स उत्तर ) यह केवल तभी लागू होता है जब आपके सिस्टम में ऐसी जानकारी होती है जो कटाई के लायक होती है और जो किसी के द्वारा या कम से कम किसी ऐसे व्यक्ति के लिए सुलभ हो, जिसके पास कटाई का ब्याज है।

नोट: आपकी बनाई गई कुंजी (थोड़े) मानव समझदार ( Sqlvogels उत्तर ) होनी चाहिए ।

यदि आपके सिस्टम को 1. से 4 की कोई आवश्यकता नहीं है, तो डेटाबेस पीके को आपके सार्वजनिक पहचानकर्ता (उत्तर के कई) के रूप में उपयोग नहीं करने का कोई कारण नहीं है। साथ ही सुरक्षा यहाँ कोई समस्या नहीं है (उत्तरों में से कई)।

Answer 5

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

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

Comments

प्रश्न है: "क्या प्राथमिक कुंजियों को उजागर करना बुरा है?" । आपका जवाब: "उपयोगकर्ता अपने स्वयं के पहचानकर्ता बनाना चाहते हैं" । मुझे रिश्ता नहीं मिला। मैं उजागर करता हूं InvoiceNumber, जिसका ग्राहक के लिए एक अर्थ है और परिवर्तनशील है, लेकिन मैं भी उजागर InvoiceIDकरता हूं, जो मेरा कोड चालान की विशिष्ट पहचान करने के लिए उपयोग करता है। आपके पास (और अधिक बार नहीं करना चाहते ) उपयोगकर्ता-कुंजी को स्टोर-कुंजी नहीं होने देना है। यह प्रश्न उत्तरार्द्ध के बारे में है।

— कोडकास्टर

मुझे लगता है कि यह एक अच्छा उदाहरण है क्योंकि यदि आप अपने एपीपी के बहु-किरायेदार संस्करण पर जाते हैं, तो आप एक ही वाक्यविन्यास रख सकते हैं और एक ही InvoiceNumber(अलग-अलग किरायेदारों के लिए) के कई चालान हैं लेकिन अलग-अलग प्राथमिक कुंजी हैं - एक बिंदु (तरह का) ) उत्तर में भी उल्लेख किया है।

— आना

@ कोडकोड यह सवाल वास्तव में "आप उन्हें एक ही क्यों नहीं करना चाहते" के बारे में है?

— एंजेलो फुच्स

उस मामले में टेलस्टाइन का जवाब देखें ।

— कोडकास्टर

Answer 6

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

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

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

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

Comments

यह निर्भर करता है ... किस पर? मैं सीखना चाहता हूं कि उस सामान्य अवधारणा के पीछे क्या कारण हैं, यह जानने के लिए कि कब इसे लागू करना है और कब नहीं।

— एंजेलो फुच्स

हाय ग्राहक, कृपया मुझे अपनी आईडी दें ताकि मैं आपकी मदद कर सकूं। ज़रूर, इसका gfds789gxb3456bgfx789fgh98076hytd6734nhg5678nghf875nhgf456। हम्म, आपके सामाजिक के बारे में कैसे? ... सरोगेट आईडी

— माइकल डुरंट

@ मिचेल, उत्तर अद्यतन। क्या यह एक परिचित, सरल और स्थिर कुंजी है?

— nvogel

Answer 7

यह CodeCaster द्वारा ग्रीस्टोन 28 के जवाब पर एक टिप्पणी से है। यह एक उदाहरण है कि आप क्या कह रहे हैं:

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

इनवॉइस सेवा के प्रबंधन में आपके ऐप का क्या उद्देश्य है?

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

Comments

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

— एंजेलो फुच्स

@AngeloNeuschitzer - यदि उपयोगकर्ता विशिष्ट रूप से ग्राहक के नाम और संख्या से चालान की पहचान कर सकता है, तो उपयोगकर्ता को इनवॉइस पीके की आवश्यकता नहीं है, लेकिन डेटाबेस और अंतर्निहित कोड इसका उपयोग कर सकते हैं। वे परस्पर अनन्य कार्य कर रहे हैं।

— जेफ़ओ

मेरे उदाहरण के मामले 1 - 3 देखें। उस किसी भी मामले में ग्राहक का नाम उपयोगकर्ता के लिए उस वस्तु को संबोधित करने का एक उपयोगी तरीका है (मानव या मशीन हो)। इनवॉइस पीके है।

— एंजेलो फुच्स

Answer 8

यह पूरी तरह से सामान्य है कि संस्थाओं के पास एक विशिष्ट पहचानकर्ता है जो बाहरी दुनिया के संपर्क में है। कुछ वस्तुओं के लिए एक पहचानकर्ता को ढूंढना संभव हो सकता है जिसका वास्तव में एक अर्थ है (उदाहरण के लिए चालान संख्या) लेकिन अन्य के लिए ऐसा कोई पहचानकर्ता मौजूद नहीं है और इसलिए इसे उत्पन्न करना होगा।

स्थिरता और पठनीयता के लिए, मुझे सिस्टम में सभी संस्थाओं के लिए उनके समान पहचानकर्ता के लिए सटीक एक ही प्रकार और नाम का उपयोग करने का अच्छा अभ्यास है। आम तौर पर इस पहचानकर्ता को <type> getId()कुछ सार आधार वर्ग में उजागर किया जाएगा ।

इसी कारण से सिस्टम में प्रत्येक सेवा (उदाहरण के लिए चालान सेवा) को अपने पहचानकर्ता द्वारा संस्थाओं तक पहुँचने के लिए समान तरीके प्रदान करने चाहिए। आम तौर पर यह विधि ( findById(<type> id)) एक सामान्य सेवा इंटरफ़ेस या आधार वर्ग से विरासत में मिली होगी।

इस पहचानकर्ता को इकाई की प्राथमिक कुंजी नहीं होना चाहिए, लेकिन यह एक हो सकता है। केवल एक चीज को सुनिश्चित करना है कि मुख्य पीढ़ी की रणनीति काफी विशिष्ट पहचानकर्ता पैदा करती है (आवश्यक रूप से अद्वितीय नहीं, लेकिन कम से कम सिस्टम के भीतर)।

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

Comments

क्या आप बता सकते हैं कि आपके उत्तर में जो उत्तर दिया गया है वह दूसरे में क्या नहीं है?

— एंजेलो फुच्स

मेरे जवाब में मैं कम से कम अंक 2. और 3. आपके सारांश से असहमत हूं। मुझे नहीं लगता कि ये ऑब्जेक्ट पहचानकर्ता के रूप में पीके का उपयोग न करने के वैध कारण हैं।

— मटन

Answer 9

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

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

लेकिन सुरक्षा में, हमारे पास कई सिद्धांत हैं (जो हम स्वीकार करते हैं और अनुमोदन नहीं करते हैं) और हमें उनका पालन करने की आवश्यकता है:

1. पट्टा विशेषाधिकार का सिद्धांत
2. अस्पष्टता के माध्यम से सुरक्षा

और कुछ अन्य सिद्धांत। वे जो अनिवार्य रूप से कहते हैं, वह है:

यदि आपको अपना डेटा उजागर करने की आवश्यकता नहीं है, तो आप क्यों करेंगे?

Comments

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

— जेन्सजी

आप ऐसा क्यों करेंगे: मैंने उस उदाहरण को देखा जो मैंने प्रश्न में जोड़ा था।

— एंजेलो फुच्स