हर महान कहानी एक पहचान संकट से शुरू होती है। ल्यूक, महान जेडी मास्टर, अनिश्चित शुरू करते हैं - "मैं कौन हूं?" - और मैं किसी के लिए महत्वपूर्ण कैसे हो सकता हूं? योदा को, जो बल के साथ है, उसे अपनी शक्तियों का उपयोग करने का तरीका सिखाने के लिए लेता है।
आज, मुझे तुम्हारा योदा बनने दो।
हम प्राथमिक कुंजी चुनने, पहचान संकट से लड़ने और फिर डेटाबेस में प्राथमिक कुंजी बनाने के लिए कोड नमूने के साथ शुरू करेंगे।
प्राथमिक कुंजी कैसे चुनें
आप सोच सकते हैं कि ल्यूक ही एकमात्र ऐसा व्यक्ति है जिसके पास पहचान का संकट है, लेकिन यह सच नहीं है। डेटाबेस बनाते समय, सब कुछ एक पहचान संकट में होता है। और यही कारण है कि हमें प्राथमिक कुंजी की आवश्यकता है:वे संकट का समाधान करते हैं। वे हमें बताते हैं कि सभी को कैसे खोजा जाए।
कल्पना कीजिए कि आप सरकार हैं, और आप अपने प्रत्येक नागरिक को डिजिटल रूप से पहचानना चाहते हैं। तो, आप इस डेटाबेस को उनके बारे में सब कुछ के साथ बनाते हैं:
First Name
Last Name
Passport Numberआप पासपोर्ट नंबर को प्राथमिक कुंजी के रूप में चुनते हैं - सभी के लिए पहचान। आपको लगता है कि आपको बस इतना ही चाहिए क्योंकि पासपोर्ट में पता और बाकी सब कुछ है। आप जानते हैं कि पासपोर्ट नंबर अद्वितीय होते हैं, इसलिए आप अच्छा महसूस करते हैं और इस प्रणाली को लागू करते हैं।
फिर, कुछ साल बाद, आपको एक बदसूरत सच्चाई का पता चलता है:पूरा देश एक पहचान संकट का सामना कर रहा है।
जब भी किसी का पासपोर्ट एक्सपायर होता है तो उसे नया पासपोर्ट मिल जाता है। उनकी पहचान बदल जाती है। अन्य सिस्टम पुराने पासपोर्ट नंबरों का उपयोग करते रहते हैं, इसलिए वे अब भूतिया लोगों की ओर इशारा करते हैं।
विशिष्टता पर्याप्त नहीं है। मान पंक्ति के पूरे जीवनकाल में नहीं बदलना चाहिए।
और फिर, आप पाते हैं कि कुछ लोग ऐसे भी हैं जिनके पास पासपोर्ट भी नहीं है। आप उन्हें अपने सिस्टम में दर्ज नहीं कर सकते, क्योंकि प्राथमिक कुंजियाँ NULL नहीं हो सकतीं . आप किसी NULL . से किसी की पहचान कैसे कर सकते हैं? कुंजी?
हर पंक्ति में एक पहचानकर्ता होना चाहिए। NULLs की अनुमति नहीं है।
अगले पुनरावृत्ति का अर्थ है एक पहचानकर्ता ढूंढना जो समय के साथ नहीं बदलता है, और एक जो सभी के पास है। भारत में, यह आधार कार्ड बन रहा है। संयुक्त राज्य अमेरिका में, सामाजिक सुरक्षा संख्या।
यदि आप एक डेटाबेस बना रहे हैं, तो उन्हें अपनी प्राथमिक कुंजी बनाएं।
कभी-कभी, आपके पास ऐसी कोई चाबी नहीं होती है। एक ऐसे देश पर विचार करें जिसके पास अभी तक कोई सामाजिक सुरक्षा संख्या नहीं है, और वे प्रत्येक नागरिक का डिजिटल रिकॉर्ड बनाना चाहते हैं। वे एक नया SSN बना सकते हैं, या वे केवल डेटाबेस की शक्ति का लाभ उठा सकते हैं, और एक सरोगेट कुंजी का उपयोग कर सकते हैं।
एक सरोगेट कुंजी का कोई वास्तविक दुनिया समकक्ष नहीं है। यह डेटाबेस के अंदर सिर्फ एक संख्या है। तो, आपके पास यह तालिका नए देश में है:
userID
First Name
Last Name
Passport Numberपासपोर्ट नंबर अद्वितीय हैं। जब भी आप किसी उपयोगकर्ता के लिए पहचानकर्ता प्राप्त करना चाहते हैं, तो आप इसे पासपोर्ट नंबर के माध्यम से प्राप्त कर सकते हैं।
उपयोगकर्ता आईडी कभी नहीं बदलता है। पासपोर्ट नंबर बदल सकता है - लेकिन यह हमेशा अद्वितीय होता है, इसलिए आपको हमेशा सही उपयोगकर्ता मिलता है। UserID एक सरोगेट . है इस देश में एक गैर-मौजूदा सामाजिक सुरक्षा संख्या के लिए।
मजेदार तथ्य:यहां पासपोर्ट नंबर भी एक कैंडिडेट कुंजी है। यह प्राथमिक कुंजी हो सकती थी, अगर यह कभी नहीं बदली। यह एक व्यावसायिक तर्क भेद है।
मुख्य उपाय यह है:जब भी आप प्राथमिक कुंजी चुनते हैं, तो पहचान संकट के बारे में सोचें . क्या यह संभव है कि भविष्य में कोई अपना पहचानकर्ता बदल सकता है? क्या हम ऐसे राज्य में प्रवेश कर सकते हैं जहां एक ही पहचानकर्ता वाले कई लोग हों?
मैं लोगों को एक उदाहरण के रूप में उपयोग करता हूं, क्योंकि यह पहचान को स्पष्ट करता है - हम जानते हैं कि प्रत्येक व्यक्ति की एक पहचान होनी चाहिए। इस सोच को अपने डेटाबेस में स्थानांतरित करें। हर चीज की एक पहचान होती है, यही कारण है कि आपको प्राथमिक कुंजी की आवश्यकता होती है।
नोट:कभी-कभी, प्राथमिक कुंजी के रूप में एक साथ कई स्तंभों का उपयोग करना संभव और वांछनीय होता है। यह एक समग्र कुंजी है।
आइए अब वास्तविक कोड उदाहरणों के साथ प्राथमिक कुंजी को परिभाषित करने का प्रयास करें। यहां दो काम करने हैं:पहला, आप प्राथमिक कुंजी की पहचान करेंगे। फिर, आप इसे डेटाबेस में परिभाषित करने के लिए सिंटैक्स सीखेंगे।
असली दुनिया का उदाहरण
मान लें कि आप एक शिपिंग स्टार्टअप चलाते हैं, बहुत कुछ Flexport की तरह। आपके पास ऐसे पैकेज हैं जिन्हें एक स्थान से दूसरे स्थान पर ले जाने की आवश्यकता है, और जहाज जो उन्हें ले जाते हैं। इसके अलावा, आपके पास ऐसे ग्राहक हैं जो इन पैकेजों का ऑर्डर दे रहे हैं।
आपको लगता है कि आपको ग्राहकों के लिए एक टेबल, पैकेज के लिए एक और परिवहन के लिए एक टेबल की आवश्यकता होगी, यह दर्शाने के लिए कि अभी कौन सा पैकेज है।
इस बारे में सोचें कि आपको किन स्तंभों की आवश्यकता होगी और प्राथमिक कुंजी क्या होनी चाहिए। यदि आप फ्लेक्सपोर्ट में एक इंजीनियर होते, तो यह एक वास्तविक प्रश्न है जिसे आपको समझना होगा। कुछ भी नहीं दिया जाता है, सब कुछ वास्तविक दुनिया में खोजा जाता है।
इस जानकारी को देखते हुए, मैं इन तालिकाओं को इस प्रकार डिज़ाइन करूँगा:
Customers: first_name, last_name, email, address (for deliveries to their location)
Packages: weight, content
Transportation: <package_primary_key>, Port, timeहम प्राथमिक कुंजी खो रहे हैं। आगे पढ़ने से पहले उनके बारे में सोचें।
पैकेज के लिए, मैं एक सरोगेट चुनूंगा पैकेज आईडी। मैं पैकेज की सभी विशेषताओं को सूचीबद्ध करने का प्रयास कर सकता था:वजन, मात्रा, घनत्व, आयु। वे विशिष्ट रूप से पैकेज की पहचान करेंगे, लेकिन व्यवहार में ऐसा करना बहुत कठिन है। लोगों को इसकी परवाह नहीं है, वे बस पैकेज को एक जगह से दूसरी जगह ले जाने की परवाह करते हैं।
तो, यह एक यादृच्छिक संख्या बनाने और आईडी के रूप में उपयोग करने के लिए समझ में आता है। यही कारण है कि आप देखते हैं कि FedEx, UPS, और हर डिलीवरी सेवा बारकोड और आईडी का उपयोग करती है। ये पैकेज को ट्रैक करने के लिए बनाई गई सरोगेट कुंजियाँ हैं।
ग्राहक के लिए, मैं एक सरोगेट चुनूंगा ग्राहक आईडी। यहां, फिर से, मेरे पास अपने ग्राहकों की सामाजिक सुरक्षा संख्या चुनने, कहने का विकल्प था। लेकिन, ग्राहक इसे मेरे साथ साझा नहीं करना चाहते हैं ताकि मैं उन्हें कुछ भेज सकूं। इस प्रकार, हम आंतरिक रूप से एक कुंजी उत्पन्न करते हैं, अपने ग्राहकों को इस कुंजी के बारे में नहीं बताते हैं, और उन्हें CustomerNo पर कॉल करना जारी रखते हैं। 345681.
मजेदार कहानी:मैं कुछ कंपनियों को जानता हूं जहां उन्होंने इस CustomerNo का पर्दाफाश किया, और ग्राहकों ने जोर देकर कहा कि उन्हें नंबर 1 मिलता है। यह बहुत प्रफुल्लित करने वाला था - इंजीनियरों को वास्तव में अपना फ्रंट-एंड कोड बदलना पड़ा:if (cust == 345681) print(1); परिवहन के लिए, मैं एक समग्र चुनूंगा पैकेज आईडी + पोर्ट + समय। यह थोड़ा और दिलचस्प है। मैं एक सरोगेट . बना सकता था यहाँ भी, और यह ठीक वैसे ही काम करेगा।
लेकिन, यहाँ अनुक्रमण का जादू है। प्राथमिक कुंजी स्वचालित रूप से एक अनुक्रमणिका प्राप्त करती है, जिसका अर्थ है कि प्राथमिक कुंजी पर खोज करना बहुत अधिक कुशल है।
जब आप इस डेटाबेस में खोज कर रहे होते हैं, तो अधिकांश प्रश्न "यह पैकेज कहां है?" के रूप में होंगे। दूसरे शब्दों में, इस पैकेज आईडी को देखते हुए, मुझे पोर्ट और समय बताएं कि यह अभी है। यदि मेरे पास यह मेरी प्राथमिक कुंजी के हिस्से के रूप में नहीं है, तो मुझे PackageID पर एक अतिरिक्त अनुक्रमणिका की आवश्यकता होगी।
क्या यह अच्छा लगता है? अंतिम चरण, आइए SQL में इन 3 तालिकाओं को परिभाषित करें। आपके द्वारा उपयोग किए जा रहे डेटाबेस के साथ सिंटैक्स थोड़ा भिन्न होता है।
MySQL में प्राथमिक कुंजी को परिभाषित करना
CREATE TABLE customers
( customerID INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
last_name VARCHAR(30) NOT NULL,
first_name VARCHAR(25) NOT NULL,
email VARCHAR(50) NOT NULL,
address VARCHAR(300)
);CREATE TABLE packages
( packageID INT(15) NOT NULL AUTO_INCREMENT,
weight DECIMAL (10, 2) NOT NULL,
content VARCHAR(50),
CONSTRAINT packages_pk PRIMARY KEY (packageID) # An alternative way to above,
# when you want to name the constraint as well.
);CREATE TABLE transportation
( package INT(15) NOT NULL,
port INT(15) NOT NULL,
time DATE NOT NULL,
PRIMARY KEY (package, port, time),
FOREIGN KEY package
REFERENCES packages(packageID)
ON DELETE RESTRICT # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted.
);Postgresql में प्राथमिक कुंजी को परिभाषित करना
CREATE TABLE customers
( customerID SERIAL NOT NULL PRIMARY KEY, # In PostgreSQL SERIAL is same as AUTO_INCREMENT - it adds 1 to every new row.
last_name VARCHAR(30) NOT NULL,
first_name VARCHAR(25) NOT NULL,
address TEXT,
email VARCHAR(50) NOT NULL
);CREATE TABLE packages
( packageID SERIAL NOT NULL,
weight NUMERIC NOT NULL,
content TEXT,
CONSTRAINT packages_pk PRIMARY KEY (packageID) # In PostgreSQL, this alternative way works too.
);CREATE TABLE transportation
( package INTEGER NOT NULL,
port INT(15) NOT NULL,
time DATE NOT NULL,
PRIMARY KEY (package, port, time),
FOREIGN KEY package
REFERENCES packages(packageID)
ON DELETE RESTRICT # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted.
);यह बहुत अलग नहीं है, है ना? एक बार जब आप मूल बातें प्राप्त कर लेते हैं, तो आप इसे दस्तावेज़ीकरण पर एक त्वरित नज़र के साथ लगभग किसी भी डेटाबेस पर लागू कर सकते हैं। कुंजी यह जानना है कि क्या देखना है!
शुभकामनाएँ, युवा पदवान।
इसका आनंद लिया? आपको मेरे द्वारा एक वरिष्ठ सॉफ्टवेयर इंजीनियर से सीखी गई बातें भी पसंद आ सकती हैं
