डेटाबेसमधील कळा

5.1 परिचय

रिलेशनल डेटाबेसमध्ये कळा कशा निवडायच्या आणि कशा वापरायच्या याविषयी इंटरनेट कट्टर नियमांनी भरलेले आहे. कधीकधी विवाद होलिव्हरमध्ये देखील बदलतात: नैसर्गिक की कृत्रिम की वापरल्या पाहिजेत? स्वयं-वाढ पूर्णांक किंवा UUID?

चौसष्ट लेख वाचून, पाच पुस्तकांच्या विभागांमध्ये फिरून, आणि IRC आणि StackOverflow वर अनेक प्रश्न विचारल्यानंतर, मी (मूळ लेखाचा लेखक जो "बेग्रिफ्स" नेल्सन) कोडे एकत्र ठेवल्यासारखे वाटते आणि आता विरोधकांशी समेट करू शकतो. अनेक मुख्य वाद प्रत्यक्षात दुसऱ्याच्या दृष्टिकोनातून गैरसमजातून उद्भवतात.

चला समस्या दूर करू आणि शेवटी एकत्र ठेवू. प्रथम, प्रश्न विचारूया - "की" म्हणजे काय?

एका क्षणासाठी प्राथमिक कळा विसरू या, आम्हाला अधिक सामान्य कल्पनांमध्ये रस आहे. की म्हणजे स्तंभ (स्तंभ) किंवा स्तंभ ज्यात पंक्तींमध्ये डुप्लिकेट मूल्ये नसतात . तसेच, स्तंभ अपरिवर्तनीयपणे अद्वितीय असले पाहिजेत, म्हणजेच स्तंभांच्या कोणत्याही उपसंचात हे वेगळेपण नाही.

परंतु प्रथम, काही सिद्धांतः

प्राथमिक कळ

प्राथमिक कळटेबलमधील पंक्ती ओळखण्यासाठी थेट वापरला जातो. हे खालील निर्बंधांचे पालन करणे आवश्यक आहे:

• प्राथमिक की सर्व वेळ अद्वितीय असणे आवश्यक आहे.
• ते नेहमी टेबलमध्ये उपस्थित असले पाहिजे आणि त्याचे मूल्य असणे आवश्यक आहे.
• त्याचे मूल्य वारंवार बदलू नये. तद्वतच, ते मूल्य अजिबात बदलू नये .

सामान्यतः, प्राथमिक की सारणीच्या एका स्तंभाचे प्रतिनिधित्व करते, परंतु ती एकापेक्षा जास्त स्तंभ असलेली संमिश्र की देखील असू शकते.

संमिश्र की

सानुकूल की- विशेषतांचे संयोजन (स्तंभ) जे प्रत्येक सारणी पंक्ती अद्वितीयपणे ओळखतात. हे सर्व स्तंभ आणि अनेक आणि एक असू शकतात. या प्रकरणात, या गुणधर्मांची मूल्ये असलेल्या ओळींची पुनरावृत्ती होऊ नये.

संभाव्य की

उमेदवार की- रिलेशन (सारणी) ची किमान संमिश्र की दर्शवते, म्हणजे, अनेक अटी पूर्ण करणारे गुणधर्मांचा संच:

• अपरिवर्तनीयता : ते कमी करता येत नाही, त्यात किमान संभाव्य गुणधर्मांचा संच असतो.
• विशिष्टता : पंक्ती बदलाची पर्वा न करता त्यात अद्वितीय मूल्ये असणे आवश्यक आहे.
• मूल्याची उपस्थिती : त्यात शून्य मूल्य नसावे, म्हणजे त्याचे मूल्य असणे आवश्यक आहे.

5.2 प्राथमिक की चे उत्सुक केस

मागील विभागात आपण ज्याला "की" म्हटले आहे त्यांना सामान्यतः "उमेदवार की" म्हणून संबोधले जाते. "उमेदवार" या शब्दाचा अर्थ असा आहे की अशा सर्व की "प्राथमिक की" (प्राथमिक की) च्या मानद भूमिकेसाठी स्पर्धा करतात आणि उर्वरित "पर्यायी की" (पर्यायी की) नियुक्त केल्या जातात.

की आणि रिलेशनल मॉडेलमधील विसंगती दूर करण्यासाठी SQL अंमलबजावणीस थोडा वेळ लागला आणि सर्वात जुने डेटाबेस प्राथमिक कीच्या निम्न-स्तरीय संकल्पनेसाठी सज्ज होते. अनुक्रमिक स्टोरेज मीडियावरील पंक्तीचे भौतिक स्थान ओळखण्यासाठी अशा डेटाबेसमधील प्राथमिक की आवश्यक होत्या. जो सेल्को हे कसे स्पष्ट करतात ते येथे आहे:

"की" या शब्दाचा अर्थ फाईल सॉर्ट की, जी अनुक्रमिक फाइल सिस्टमवर कोणतीही प्रक्रिया ऑपरेशन करण्यासाठी आवश्यक होती. पंच केलेल्या कार्ड्सचा संच एकाच क्रमाने वाचला गेला; परत जाणे अशक्य होते. सुरुवातीच्या टेप ड्राइव्हने समान वर्तनाची नक्कल केली आणि द्विदिश प्रवेशास परवानगी दिली नाही. म्हणजेच, मूळ Sybase SQL सर्व्हरला मागील पंक्ती वाचण्यासाठी सारणीला सुरवातीला “रिवाइंड” करणे आवश्यक आहे.

आधुनिक SQL मध्ये, तुम्हाला माहितीचे भौतिक प्रतिनिधित्व, टेबल मॉडेल संबंधांवर लक्ष केंद्रित करण्याची आवश्यकता नाही आणि पंक्तींचा अंतर्गत क्रम अजिबात महत्त्वाचा नाही. तथापि, आताही SQL सर्व्हर बाय डीफॉल्ट प्राथमिक की साठी क्लस्टर केलेला अनुक्रमणिका तयार करतो आणि जुन्या परंपरेनुसार, पंक्तींचा क्रम भौतिकरित्या व्यवस्थित करतो.

बहुतेक डेटाबेसमध्ये, प्राथमिक की ही भूतकाळातील गोष्ट आहे आणि प्रतिबिंब किंवा भौतिक स्थानापेक्षा थोडे अधिक प्रदान करते. उदाहरणार्थ, PostgreSQL टेबलमध्ये, प्राथमिक की घोषित केल्याने आपोआप मर्यादा लागू होते NOT NULLआणि डीफॉल्ट परदेशी की परिभाषित होते. याव्यतिरिक्त, ऑपरेटरसाठी प्राथमिक की हे प्राधान्य दिलेले स्तंभ आहेत JOIN.

प्राथमिक की इतर की घोषित करण्याची शक्यता ओव्हरराइड करत नाही. त्याच वेळी, प्राथमिक म्हणून कोणतीही की नियुक्त केलेली नसल्यास, टेबल अद्याप चांगले कार्य करेल. वीज, कोणत्याही परिस्थितीत, तुम्हाला धडकणार नाही.

5.3 नैसर्गिक कळा शोधणे

वर चर्चा केलेल्या कळांना "नैसर्गिक" म्हटले जाते कारण ते मॉडेल केलेल्या ऑब्जेक्टचे गुणधर्म आहेत जे स्वतःमध्ये स्वारस्यपूर्ण आहेत, जरी कोणीही त्यांच्यामधून की बनवू इच्छित नसला तरीही.

संभाव्य नैसर्गिक की साठी टेबल तपासताना लक्षात ठेवण्याची पहिली गोष्ट म्हणजे खूप स्मार्ट न होण्याचा प्रयत्न करणे. StackExchange वर वापरकर्ता sqlvogel खालील सल्ला देतो:

काही लोकांना "नैसर्गिक" की निवडण्यात अडचण येते कारण ते काल्पनिक परिस्थितींसह येतात ज्यामध्ये विशिष्ट की अद्वितीय असू शकत नाही. त्यांना कामाचा नेमका अर्थ कळत नाही. की चा अर्थ असा नियम परिभाषित करणे आहे ज्यानुसार विशिष्ट टेबलमध्ये कोणत्याही वेळी गुणधर्म असणे आवश्यक आहे आणि नेहमी अद्वितीय असणे आवश्यक आहे. सारणीमध्ये विशिष्ट आणि चांगल्या प्रकारे समजल्या जाणार्‍या संदर्भातील डेटा समाविष्ट आहे ("विषय क्षेत्र" किंवा "प्रवचन क्षेत्र" मध्ये), आणि त्या विशिष्ट क्षेत्रातील निर्बंध लागू करणे हा एकमेव अर्थ आहे.

सराव दर्शविते की जेव्हा उपलब्ध मूल्यांसह स्तंभ अद्वितीय असेल आणि संभाव्य परिस्थितींमध्ये तो तसाच राहील तेव्हा मुख्य प्रतिबंध सादर करणे आवश्यक आहे. आणि आवश्यक असल्यास, निर्बंध काढले जाऊ शकतात (जर हे तुम्हाला त्रास देत असेल तर खाली आम्ही मुख्य स्थिरतेबद्दल बोलू.)

उदाहरणार्थ, हॉबी क्लब सदस्यांच्या डेटाबेसमध्ये दोन स्तंभांमध्ये विशिष्टता असू शकते - first_name, last_name. थोड्या प्रमाणात डेटासह, डुप्लिकेट असण्याची शक्यता नाही आणि वास्तविक संघर्ष उद्भवण्यापूर्वी, अशी की वापरणे अगदी वाजवी आहे.

जसजसा डेटाबेस वाढत जातो आणि माहितीचे प्रमाण वाढते तसतसे नैसर्गिक की निवडणे अधिक कठीण होऊ शकते. आम्ही संचयित करतो तो डेटा बाह्य वास्तवाचे एक सरलीकरण आहे आणि त्यात काही पैलू नसतात जे जगातील वस्तूंना वेगळे करतात, जसे की त्यांचे समन्वय वेळोवेळी बदलतात. जर एखाद्या वस्तूमध्ये कोणताही कोड नसेल, तर तुम्ही दोन कॅन पेय किंवा ओटचे जाडे भरडे पीठ यांचे दोन बॉक्स त्यांच्या अवकाशीय व्यवस्थेशिवाय किंवा वजन किंवा पॅकेजिंगमध्ये थोडा फरक कसा सांगू शकता?

म्हणूनच मानकीकरण संस्था उत्पादनांना विशिष्ट गुण तयार करतात आणि लागू करतात. वाहनांवर व्हेईकल आयडेंटिफिकेशन नंबर (VIN) चा शिक्का मारला जातो , पुस्तके ISBN ने छापली जातात आणि फूड पॅकेजिंगमध्ये UPC असतात . तुम्ही आक्षेप घेऊ शकता की हे आकडे नैसर्गिक वाटत नाहीत. मग मी त्यांना नैसर्गिक की का म्हणू?

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

चलने, भाषा, आर्थिक साधने, रसायने आणि वैद्यकीय निदानांसह विविध विषयांसाठी अनेक उद्योग, सार्वजनिक आणि आंतरराष्ट्रीय मानके आहेत. येथे काही मूल्ये आहेत जी सहसा नैसर्गिक की म्हणून वापरली जातात:

• ISO 3166 देश कोड
• ISO 639 भाषा कोड
• आयएसओ 4217 नुसार चलन कोड
• स्टॉक चिन्हे ISIN
• UPC/EAN, VIN, GTIN, ISBN
• लॉगिन नावे
• ईमेल पत्ते
• खोली क्रमांक
• नेटवर्क मॅक पत्ता
• पृथ्वीच्या पृष्ठभागावरील बिंदूंसाठी अक्षांश, रेखांश

मी जेव्हा शक्य असेल तेव्हा आणि वाजवी की घोषित करण्याची शिफारस करतो, कदाचित प्रति टेबल अनेक की. परंतु लक्षात ठेवा की वरील सर्व अपवाद असू शकतात.

• प्रत्येकाकडे ईमेल पत्ता नसतो, जरी हे काही डेटाबेस परिस्थितीनुसार स्वीकार्य असू शकते. तसेच, लोक वेळोवेळी त्यांचे ईमेल पत्ते बदलतात. (की स्थिरतेबद्दल नंतर अधिक.)
• ISIN स्टॉक चिन्हे वेळोवेळी बदलतात, उदाहरणार्थ, GOOG आणि GOOGL ही चिन्हे Google ते Alphabet पर्यंत कंपनीच्या पुनर्रचनाचे अचूक वर्णन करत नाहीत. काहीवेळा गोंधळ निर्माण होऊ शकतो, TWTR आणि TWTRQ प्रमाणे, काही गुंतवणूकदारांनी चुकून Twitter IPO दरम्यान नंतरचे खरेदी केले.
• सामाजिक सुरक्षा क्रमांक फक्त यूएस नागरिक वापरतात, गोपनीयतेवर बंधने असतात आणि मृत्यूनंतर पुन्हा वापरतात. याशिवाय, कागदपत्रांची चोरी झाल्यानंतर लोकांना नवीन क्रमांक मिळू शकतात. शेवटी, समान क्रमांक व्यक्ती आणि आयकर ओळखकर्ता दोघांनाही ओळखू शकतो.
• शहरांसाठी पिन कोड हा एक खराब पर्याय आहे. काही शहरांमध्ये एक समान निर्देशांक असतो, किंवा त्याउलट, एका शहरात अनेक निर्देशांक असतात.

5.4 कृत्रिम कळा

की प्रत्येक पंक्तीमध्ये अद्वितीय मूल्यांसह एक स्तंभ आहे हे लक्षात घेऊन, ते तयार करण्याचा एक मार्ग म्हणजे फसवणूक करणे - आपण प्रत्येक पंक्तीमध्ये काल्पनिक अद्वितीय मूल्ये लिहू शकता. या कृत्रिम कळा आहेत: डेटा किंवा वस्तूंचा संदर्भ देण्यासाठी वापरला जाणारा शोध कोड.

कोड डेटाबेसमधूनच तयार केला जातो आणि डेटाबेसच्या वापरकर्त्यांशिवाय इतर कोणालाही तो अज्ञात आहे हे खूप महत्वाचे आहे. हे प्रमाणित नैसर्गिक की पासून कृत्रिम की वेगळे करते.

टेबलमधील डुप्लिकेट किंवा विसंगत पंक्तींपासून संरक्षण करण्याचा नैसर्गिक कीचा फायदा असला तरी, कृत्रिम की उपयुक्त आहेत कारण त्या पंक्तीचा संदर्भ घेणे मानवांना किंवा इतर प्रणालींना सोपे बनवतात, आणि ते लुकअप आणि जोडण्याला गती देतात कारण ते वापरत नाहीत. स्ट्रिंग (किंवा मल्टी-कॉलम) तुलना. की.

सरोगेट्स

कृत्रिम की अँकर म्हणून वापरल्या जातात - नियम आणि स्तंभ कसे बदलले तरीही, एक पंक्ती नेहमी त्याच प्रकारे ओळखली जाऊ शकते. या उद्देशासाठी वापरल्या जाणार्‍या कृत्रिम कीला "सरोगेट की" म्हणतात आणि त्यावर विशेष लक्ष देण्याची आवश्यकता असते. आम्ही खाली सरोगेट्सचा विचार करू.

डेटाबेसच्या बाहेरील पंक्तीचा संदर्भ देण्यासाठी गैर-सरोगेट कृत्रिम की उपयुक्त आहेत. कृत्रिम की डेटा किंवा ऑब्जेक्टची थोडक्यात ओळख करते: ती URL म्हणून निर्दिष्ट केली जाऊ शकते, इन्व्हॉइसशी संलग्न केली जाऊ शकते, फोनवर निर्देशित केली जाऊ शकते, बँकेकडून मिळवली जाते किंवा परवाना प्लेटवर मुद्रित केली जाऊ शकते. (कारची लायसन्स प्लेट ही आमच्यासाठी नैसर्गिक की आहे, परंतु सरकारने कृत्रिम की म्हणून डिझाइन केली आहे.)

टायपो आणि चुका कमी करण्यासाठी ट्रान्समिशनच्या संभाव्य माध्यमांचा विचार करून सिंथेटिक की निवडल्या पाहिजेत. हे लक्षात घ्यावे की की बोलली जाऊ शकते, मुद्रित केली जाऊ शकते, एसएमएसद्वारे पाठविली जाऊ शकते, हस्तलिखीत वाचू शकते, कीबोर्डवरून टाइप केली जाऊ शकते आणि URL मध्ये एम्बेड केली जाऊ शकते. याव्यतिरिक्त, काही कृत्रिम कळा, जसे की क्रेडिट कार्ड क्रमांक, चेकसम असतात जेणेकरून काही त्रुटी आढळल्यास, त्या किमान ओळखल्या जाऊ शकतात.

उदाहरणे:

• यूएस लायसन्स प्लेट्ससाठी, O आणि 0 सारख्या अस्पष्ट वर्णांच्या वापराबाबत नियम आहेत.
• डॉक्टरांचे हस्ताक्षर लक्षात घेता रुग्णालये आणि फार्मसीने विशेषतः सावधगिरी बाळगणे आवश्यक आहे.
• तुम्ही मजकूर संदेशाद्वारे पुष्टीकरण कोड पाठवता का? GSM 03.38 वर्ण संचाच्या पलीकडे जाऊ नका.
• Base64 च्या विपरीत, जो अनियंत्रित बाइट डेटा एन्कोड करतो, Base32 मर्यादित वर्ण संच वापरतो जो मनुष्यांना जुन्या संगणक प्रणालींवर वापरण्यासाठी आणि हाताळण्यासाठी सोयीस्कर आहे.
• Proquints वाचनीय, लिहिण्यायोग्य आणि उच्चारण्यायोग्य अभिज्ञापक आहेत. हे निःसंदिग्धपणे समजलेल्या व्यंजन आणि स्वरांचे PRO-nouncable QUINT-अपलेट्स आहेत.

लक्षात ठेवा की आपण आपली कृत्रिम की जगासमोर आणताच, लोक विचित्रपणे त्याकडे विशेष लक्ष देण्यास सुरवात करतील. फक्त "चोर" परवाना प्लेट्स पहा किंवा उच्चार करण्यायोग्य अभिज्ञापक तयार करण्यासाठी सिस्टमकडे पहा, जे कुप्रसिद्ध स्वयंचलित शाप जनरेटर बनले आहे.

जरी आपण स्वतःला संख्यात्मक कळांपुरते मर्यादित ठेवले तरी तेराव्या मजल्यासारखे निषिद्ध आहेत. प्रॉक्विंट्समध्ये प्रत्येक उच्चारात माहितीची घनता जास्त असते, तर संख्या अनेक प्रकारे ठीक असतात: URL, पिन-कीबोर्ड आणि हस्तलिखित नोट्समध्ये, जोपर्यंत प्राप्तकर्त्याला कळते की फक्त संख्या असते.

तथापि, कृपया लक्षात ठेवा की तुम्ही सार्वजनिक अंकीय की मध्ये अनुक्रमिक क्रम वापरू नये, कारण हे तुम्हाला संसाधनांद्वारे (/videos/1.mpeg, /videos/2.mpeg, आणि असेच) रमेज करण्यास अनुमती देते आणि नंबरबद्दल माहिती लीक देखील करते. डेटा संख्यांच्या क्रमवारीवर फीस्टेल नेट वरती लावा आणि संख्यांचा क्रम लपवताना वेगळेपण जतन करा.

अतिरिक्त की घोषित करण्याच्या विरोधात एकच युक्तिवाद असा आहे की प्रत्येक नवीन आपल्याबरोबर आणखी एक अद्वितीय निर्देशांक आणते आणि टेबलवर लिहिण्याची किंमत वाढवते. अर्थात, डेटाची शुद्धता आपल्यासाठी किती महत्त्वाची आहे यावर अवलंबून आहे, परंतु, बहुधा, की अद्याप घोषित केल्या पाहिजेत.

काही कृत्रिम की, असल्यास, घोषित करणे देखील योग्य आहे. उदाहरणार्थ, एखाद्या संस्थेमध्ये नोकरीचे उमेदवार (अर्जदार) आणि कर्मचारी (कर्मचारी) असतात. प्रत्येक कर्मचारी एकेकाळी उमेदवार होता, आणि उमेदवारांना त्यांच्या स्वतःच्या ओळखकर्त्याद्वारे संदर्भित करतो, जी कर्मचार्‍यांची की देखील असावी. दुसरे उदाहरण, तुम्ही कर्मचारी आयडी आणि लॉगिन नाव कर्मचारी मध्ये दोन की म्हणून सेट करू शकता.

5.5 सरोगेट की

आधीच नमूद केल्याप्रमाणे, कृत्रिम किल्लीच्या महत्त्वाच्या प्रकाराला "सरोगेट की" म्हणतात. हे इतर कृत्रिम कींप्रमाणे संक्षिप्त आणि पास करण्यायोग्य असण्याची गरज नाही, परंतु स्ट्रिंग नेहमी ओळखणारे अंतर्गत लेबल म्हणून वापरले जाते. हे SQL मध्ये वापरले जाते, परंतु अनुप्रयोग स्पष्टपणे त्यात प्रवेश करत नाही.

जर तुम्ही PostgreSQL च्या सिस्टम कॉलमशी परिचित असाल, तर तुम्ही सरोगेट्सचा विचार जवळजवळ डेटाबेस अंमलबजावणी पॅरामीटर (ctid सारखा) म्हणून करू शकता, जे तथापि, कधीही बदलत नाही. सरोगेट मूल्य प्रति पंक्ती एकदा निवडले जाते आणि त्यानंतर कधीही बदलले जात नाही.

ON UPDATE RESTRICTसरोगेट की विदेशी की म्हणून उत्तम आहेत आणि सरोगेटच्या अपरिवर्तनीयतेशी जुळण्यासाठी कॅस्केडिंग मर्यादा निर्दिष्ट केल्या पाहिजेत .

दुसरीकडे, ON UPDATE CASCADEजास्तीत जास्त लवचिकता प्रदान करण्यासाठी, सार्वजनिकपणे सामायिक केलेल्या की वरील परदेशी की सह चिन्हांकित केल्या पाहिजेत. कॅस्केडिंग अपडेट आजूबाजूच्या व्यवहाराप्रमाणेच आयसोलेशन स्तरावर चालते, त्यामुळे कॉन्करन्सी समस्यांबद्दल काळजी करू नका - तुम्ही कठोर अलगाव पातळी निवडल्यास डेटाबेस ठीक होईल.

सरोगेट की "नैसर्गिक" बनवू नका. एकदा तुम्ही अंतिम वापरकर्त्यांना सरोगेट कीचे मूल्य दाखवले किंवा वाईट, त्यांना त्या मूल्यासह कार्य करू द्या (विशेषतः लुकअपद्वारे), तुम्ही प्रभावीपणे कीला मूल्य देत आहात. मग तुमच्या डेटाबेसमधून दाखवलेली की दुसऱ्याच्या डेटाबेसमध्ये नैसर्गिक की बनू शकते.

बाह्य प्रणालींना विशेषत: प्रसारणासाठी डिझाइन केलेल्या इतर कृत्रिम की वापरण्यास भाग पाडणे आम्हाला सरोगेट्ससह अंतर्गत संदर्भ अखंडता राखून बदलत्या गरजा पूर्ण करण्यासाठी आवश्यक त्या की बदलण्याची परवानगी देते.

स्वयं-वाढ INT/BIGINT

सरोगेट की चा सर्वात सामान्य वापर म्हणजे स्वयं-वृद्धी करणारा "बिगसीरियल" स्तंभ , ज्याला ओळख म्हणून देखील ओळखले जाते . (खरं तर, PostgreSQL 10 आता Oracle प्रमाणे IdentITY रचनेला सपोर्ट करते, CREATE TABLE पहा.)

तथापि, माझा विश्वास आहे की स्वयं-वृद्धी पूर्णांक ही सरोगेट की साठी खराब निवड आहे. हे मत लोकप्रिय नाही, म्हणून मी स्पष्ट करू.

सिरीयल कीचे तोटे:

• जर सर्व क्रम 1 पासून सुरू झाले आणि वाढत्या प्रमाणात वाढले, तर वेगवेगळ्या सारण्यांवरील पंक्तींची समान मूल्ये असतील. हा पर्याय आदर्श नाही, तरीही टेबलमध्ये कीजचे डिसजॉइंट सेट वापरणे श्रेयस्कर आहे, जेणेकरून, उदाहरणार्थ, क्वेरी चुकून स्थिरांकांना गोंधळात टाकू शकत नाहीत JOINआणि अनपेक्षित परिणाम देऊ शकत नाहीत. (वैकल्पिकरित्या, कोणतेही छेदनबिंदू नाहीत याची खात्री करण्यासाठी, भिन्न प्राइमच्या गुणाकारांमधून प्रत्येक अनुक्रम तयार केला जाऊ शकतो, परंतु हे खूप कष्टदायक असेल.)
• आजच्या वितरीत SQL मध्ये एक क्रम तयार करण्यासाठी कॉल केल्याने nextval() संपूर्ण सिस्टम चांगले स्केलिंग होत नाही.
• अनुक्रमिक की देखील वापरणार्‍या डेटाबेसमधील डेटा वापरल्याने संघर्ष होईल कारण अनुक्रमिक मूल्ये संपूर्ण सिस्टममध्ये अद्वितीय नसतील.
• तात्विक दृष्टिकोनातून, संख्यांमध्ये अनुक्रमिक वाढ जुन्या प्रणालींशी संबंधित आहे ज्यामध्ये ओळींचा क्रम निहित होता. जर तुम्हाला आता पंक्ती ऑर्डर करायच्या असतील, तर टाइमस्टॅम्प कॉलम किंवा तुमच्या डेटामध्ये अर्थपूर्ण असे काहीतरी स्पष्टपणे करा. अन्यथा, प्रथम सामान्य स्वरूपाचे उल्लंघन केले जाते.
• कमकुवत कारण, परंतु हे लहान ओळखकर्ते कोणालातरी सांगण्याचा मोह करतात.

UUID

चला दुसरा पर्याय पाहू: यादृच्छिक पॅटर्ननुसार तयार केलेले मोठे पूर्णांक (128-बिट) वापरणे. अशा युनिव्हर्सली युनिक आयडेंटिफायर्स (UUIDs) व्युत्पन्न करण्यासाठी अल्गोरिदममध्ये एकाच वेळी दोन भिन्न प्रोसेसर चालत असतानाही, समान मूल्य दोनदा निवडण्याची अत्यंत कमी संभाव्यता असते.

अशावेळी, UUIDs हे सरोगेट की म्हणून वापरण्याची नैसर्गिक निवड असल्यासारखे वाटते, नाही का? जर तुम्हाला पंक्तींना अनन्य पद्धतीने लेबल करायचे असेल, तर अनन्य लेबलवर काहीही फरक पडत नाही!

मग प्रत्येकजण PostgreSQL मध्ये त्यांचा वापर का करत नाही? याची अनेक काल्पनिक कारणे आहेत आणि एक तार्किक कारणे शोधली जाऊ शकतात आणि मी माझा मुद्दा स्पष्ट करण्यासाठी बेंचमार्क सादर करेन.

प्रथम, मी दूरगामी कारणांबद्दल बोलू. काही लोकांना वाटते की UUID स्ट्रिंग आहेत कारण ते डॅशसह पारंपारिक हेक्साडेसिमल नोटेशनमध्ये लिहिलेले आहेत: 5bd68e64-ff52-4f54-ace4-3cd9161c8b7f. खरंच, काही डेटाबेसेसमध्ये कॉम्पॅक्ट (128-बिट) uuid प्रकार नसतो, परंतु PostgreSQL मध्ये असतो आणि त्याचा आकार दोन असतो bigint, म्हणजे डेटाबेसमधील इतर माहितीच्या तुलनेत, ओव्हरहेड नगण्य असते.

UUID सुद्धा अवजड असल्याचा अन्यायकारक आरोप आहे, पण त्यांचा उच्चार कोण करेल, टाईप करेल किंवा वाचेल? आम्ही म्हणालो की कृत्रिम की दर्शविल्या जाणे अर्थपूर्ण आहे, परंतु कोणीही (व्याख्यानुसार) सरोगेट UUID पाहू नये. हे शक्य आहे की सिस्टम डीबग करण्यासाठी psql मध्ये SQL कमांड चालवणाऱ्या डेव्हलपरद्वारे UUID हाताळले जाईल, परंतु ते इतकेच आहे. आणि विकसक अधिक सोयीस्कर की वापरून स्ट्रिंग्सचा संदर्भ घेऊ शकतो, जर त्या दिल्या असतील.

UUIDs ची खरी समस्या अशी आहे की अत्यंत यादृच्छिक मूल्यांमुळे लेखन-पुढे लॉग (WAL) वर पूर्ण पृष्ठ लिहिल्यामुळे लेखन प्रवर्धन होते . तथापि, कार्यक्षमतेचे ऱ्हास प्रत्यक्षात UUID जनरेशन अल्गोरिदमवर अवलंबून असते.

चला लेखन प्रवर्धन मोजू . खरं तर, समस्या जुन्या फाइल सिस्टममध्ये आहे. जेव्हा PostgreSQL डिस्कवर लिहिते तेव्हा ते डिस्कवरील "पृष्ठ" बदलते. जर तुम्ही कॉम्प्युटरची पॉवर बंद केली, तर बहुतांश फाइल सिस्टम डिस्कवर डेटा सुरक्षितपणे साठवण्यापूर्वी यशस्वी लेखनाची तक्रार करतील. जर PostgreSQL ला अशी क्रिया पूर्ण झाल्याची जाणीव झाली, तर पुढील सिस्टम बूट दरम्यान डेटाबेस दूषित होईल.

पोस्टग्रेएसक्यूएल सातत्य प्रदान करण्यासाठी बहुतेक ऑपरेटिंग सिस्टम्स/फाइल सिस्टम्स/डिस्क कॉन्फिगरेशनवर विश्वास ठेवू शकत नसल्यामुळे, डेटाबेस बदललेल्या डिस्क पृष्ठाची संपूर्ण स्थिती राइट-अहेड लॉगमध्ये जतन करतो ज्याचा वापर संभाव्य क्रॅशमधून पुनर्प्राप्त करण्यासाठी केला जाऊ शकतो. UUID सारख्या अत्यंत यादृच्छिक मूल्यांच्या अनुक्रमणिकेमध्ये सामान्यत: वेगवेगळ्या डिस्क पृष्ठांचा समावेश असतो आणि परिणामी प्रत्येक नवीन एंट्रीसाठी संपूर्ण पृष्ठ आकार (सहसा 4 किंवा 8 KB) WAL वर लिहिला जातो. हे तथाकथित पूर्ण-पृष्ठ लेखन आहे (पूर्ण-पृष्ठ लेखन, FPW).

काही UUID जनरेशन अल्गोरिदम (जसे की Twitter चे "स्नोफ्लेक" किंवा पोस्टग्रेएसक्यूएलच्या uuid-ossp विस्तारातील uuid_generate_v1() प्रत्येक मशीनवर मोनोटोनिकली वाढणारी मूल्ये व्युत्पन्न करतात. हा दृष्टीकोन कमी डिस्क पृष्ठांमध्ये लेखन एकत्रित करतो आणि FPW कमी करतो.

5.6 निष्कर्ष आणि शिफारसी

आता आम्ही विविध प्रकारच्या की आणि त्यांचे उपयोग पाहिले आहेत, मला तुमच्या डेटाबेसमध्ये त्या वापरण्यासाठी माझ्या शिफारसींची यादी करायची आहे.

प्रत्येक टेबलसाठी:

• सर्व नैसर्गिक की परिभाषित करा आणि घोषित करा.
• च्या डीफॉल्ट मूल्यासह UUID<table_name>_id प्रकाराची सरोगेट की तयार करा . तुम्ही ती प्राथमिक की म्हणून चिन्हांकित देखील करू शकता. आपण या अभिज्ञापकात सारणीचे नाव जोडल्यास, हे सोपे होईल , म्हणजे. ऐवजी प्राप्त करा . ही की क्लायंटला देऊ नका आणि डेटाबेसच्या बाहेर अजिबात उघड करू नका.uuid_generate_v1()JOINJOIN foo USING (bar_id)JOIN foo ON (foo.bar_id = bar.id)
• मधून जाणार्‍या इंटरमीडिएट टेबलसाठी JOIN, सर्व परदेशी की कॉलम्स एकच संयुक्त प्राथमिक की म्हणून घोषित करा.
• वैकल्पिकरित्या, एक कृत्रिम की जोडा जी URL किंवा इतर स्ट्रिंग संदर्भ संकेतांमध्ये वापरली जाऊ शकते. स्वयं-वृद्धी पूर्णांक बाहेर काढण्यासाठी Feistel ग्रिड किंवा pg_hashids वापरा .
• ON UPDATE RESTRICTसरोगेट UUIDs चा विदेशी की म्हणून आणि कृत्रिम परदेशी की साठी वापरून कॅस्केडिंग मर्यादा निर्दिष्ट करा ON UPDATE CASCADE. तुमच्या स्वतःच्या तर्कावर आधारित नैसर्गिक की निवडा.

हा दृष्टीकोन नैसर्गिक कळांना परवानगी देताना आणि संरक्षित करताना अंतर्गत की ची स्थिरता सुनिश्चित करतो. याव्यतिरिक्त, दृश्यमान कृत्रिम कळा कशाशीही जोडल्या जात नाहीत. सर्वकाही योग्यरित्या समजून घेतल्यावर, आपण केवळ "प्राथमिक की" वर टांगू शकत नाही आणि की वापरण्याच्या सर्व शक्यता वापरू शकत नाही.