कॉलम नाम बदलना

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

आइए एक प्रश्न लिखें, जहां केवल आवश्यक कॉलम होंगे, और समान नामों वाले कॉलम का नाम भी बदलें:

SELECT  
    task.id AS task_id,  
    task.name AS task_desc, 
    task.deadline AS deadline, 
    emploee.id AS emploee_id,  
    emploee.name AS emp_name,  
emploee.occupation AS	
    emp_occupation 
FROM employee, task
WHERE emploee.id = task.emploee_id

और इस प्रश्न का परिणाम:

कार्य_आईडी टास्क_डेस्क अंतिम तारीख कर्मचारी_आईडी emp_name emp_पेशा
1 दृश्यपटल पर एक बग ठीक करें 2022-06-01 1 इवानोव इवान प्रोग्रामर
2 बैकएंड पर एक बग ठीक करें 2022-06-15 2 पेट्रोव पेट्र प्रोग्रामर
7 जीवन का आनंद लें (व्यर्थ) 4 राबिनोविच मोइशा निदेशक
3 कॉफी खरीदें 2022-07-01 5 किरिंको अनास्तासिया कार्यालय प्रबंधक
4 कॉफी खरीदें 2022-08-01 5 किरिंको अनास्तासिया कार्यालय प्रबंधक
5 कॉफी खरीदें 2022-09-01 5 किरिंको अनास्तासिया कार्यालय प्रबंधक
8 जीवन का आनंद लें (व्यर्थ) 6 वास्का बिल्ली

बढ़िया, समझ में न आने वाले कॉलम नामों की समस्या को सफलतापूर्वक हल कर दिया गया है। क्वेरी थोड़ी लंबी हो गई है, लेकिन परिणामी तालिका में सब कुछ स्पष्ट है। और कोई अतिरिक्त कॉलम नहीं।

टेबल उपनाम

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

उपनाम (तालिका उपनाम) का सामान्य रूप इस प्रकार है:

FROM table1 alias1, table2 alias2

आइए अपनी पिछली क्वेरी को छोटे उपनामों के साथ फिर से लिखें:

SELECT  
    t.id AS task_id,  
    t.name AS task_desc, 
    t.deadline AS deadline, 
    e.id AS emploee_id,  
    e.name AS emp_name,  
    e.occupation AS emp_occupation 
    FROM employee e, task t 
WHERE e.id = t.emploee_id

पठनीयता थोड़ी कम हुई है, लेकिन ऐसा इसलिए है क्योंकि तालिकाओं के नाम प्रारंभ में सरल और स्पष्ट थे। यह ऐसा भी हो सकता है:

SELECT  
  	task.id AS task_id,  
  	task.name AS task_desc, 
  	task.deadline AS deadline, 
  	emploee.id AS emploee_id,  
  	emploee.name AS emp_name,  
emploee.occupation AS	
  	emp_occupation 
FROM  
  	Microsoft_it_department_employee employee, 
  	Year2022_priority_task task 
WHERE emploee.id = task.emploee_id 

और इस मामले में उपनाम पहले से ही उपयोगी हैं, है ना? ;)

प्राथमिक कुंजी

और तालिकाओं के बारे में एक और महत्वपूर्ण जानकारी। याद रखें कि हमारे पास कार्य तालिका में एक कर्मचारी_आईडी कॉलम था? इसके साथ, हमने कर्मचारी तालिका से कर्मचारी आईडी का संदर्भ दिया।

यदि हम एक तालिका से दूसरी तालिका की पंक्तियों को संदर्भित करना चाहते हैं, तो संदर्भित तालिका में एक आईडी वाला कॉलम होना चाहिए, जिसे प्राथमिक कुंजी - प्राथमिक कुंजी भी कहा जाता है

अक्सर, यह एक विशेष रूप से जोड़ा गया कॉलम होता है जिसका मान प्रकार int होता है । तालिका में रिकॉर्ड जोड़ते समय, SQL स्वचालित रूप से इस कॉलम का मान सेट करता है।

फिर इन चाबियों से बहुत सी चीजें जुड़ी हुई हैं:

  • विभिन्न तालिकाओं को एक दूसरे से जोड़ना;
  • आईडी द्वारा त्वरित खोज और फ़िल्टरिंग;
  • डेटाबेस में डेटा अखंडता (गैर-मौजूद आईडी का कोई संदर्भ नहीं);
  • उस डेटा को हटाना जिसे कोई संदर्भित नहीं करता है;
  • और कई अन्य।

वैसे, ऐसी स्थितियाँ होती हैं जब तालिका में एक तथाकथित प्राकृतिक कुंजी होती है । यह तब होता है जब एक स्तंभ होता है जिसकी सामग्री विशिष्टता दर्शाती है। उदाहरण के लिए, हमने कर्मचारी तालिका में जोड़ने का निर्णय लिया:

  • कंपनी में उनके आने का क्रम;
  • कर नंबर;
  • पासपोर्ट की संख्या और श्रृंखला।

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

मुझे लगता है कि आप इंटरनेट पर कहानियाँ पढ़ते हैं जब बेलीफ किसी व्यक्ति पर उसके पूरे नाम का कर्ज लटकाते हैं? यह सिर्फ एक अनूठी कुंजी की अवधारणा से संबंधित है। बैंकों और जमानतदारों के लिए किसी व्यक्ति को पूरा नाम और जन्म वर्ष खोजना बहुत सुविधाजनक है। और 99% मामलों में यह किसी व्यक्ति की पहचान करने के लिए पर्याप्त होता है।

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