उपनाम

स्तंभांची नावे बदलत आहे

आपल्याला स्तंभांच्या नावांशी देखील व्यवहार करणे आवश्यक आहे. अन्यथा, आम्ही नावे नाव आणि आयडीची पुनरावृत्ती करतो, परंतु त्यात भिन्न डेटा असतो. दुसरीकडे, पहिला आयडी स्तंभ आणि कर्मचारी_आयडी स्तंभ आहे, ज्यामध्ये समान डेटा आहे.

चला एक क्वेरी लिहू, जिथे फक्त आवश्यक स्तंभ असतील आणि त्याच नावांनी स्तंभांचे नाव बदलू:

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

आणि या क्वेरीचा परिणाम:

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

सारणी उपनाम

कधीकधी टेबलची नावे खूप मोठी असतात आणि क्वेरीमध्ये खूप जागा घेतात. म्हणून, 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 

आणि या प्रकरणात, उपनाव आधीच उपयुक्त आहेत, बरोबर? ;)

प्राथमिक कळ

आणि टेबलांबद्दल आणखी एक महत्त्वाची माहिती. आमच्याकडे टास्क टेबलमध्ये कर्मचारी_आयडी स्तंभ होता हे लक्षात ठेवा? त्यासह, आम्ही कर्मचारी टेबलवरून कर्मचारी आयडीचा संदर्भ दिला.

जर आपल्याला एका सारणीतून दुसऱ्या सारणीच्या पंक्तीचा संदर्भ घ्यायचा असेल, तर संदर्भित सारणीमध्ये आयडी असलेला स्तंभ असणे आवश्यक आहे, ज्याला प्राथमिक की - PRIMARY KEY देखील म्हणतात .

बर्‍याचदा, हा एक विशेष जोडलेला स्तंभ आहे ज्याचा मूल्य प्रकार int आहे . टेबलमध्ये रेकॉर्ड जोडताना, SQL आपोआप या स्तंभाचे मूल्य सेट करते.

मग या कळांशी बर्‍याच गोष्टी जोडल्या जातात:

• वेगवेगळ्या टेबल्स एकमेकांशी जोडणे;
• आयडीद्वारे द्रुत शोध आणि फिल्टरिंग;
• डेटाबेसमधील डेटा अखंडता (अस्तित्वात नसलेल्या आयडीचा संदर्भ नाही);
• कोणीही संदर्भित नसलेला डेटा हटवणे;
• आणि इतर अनेक.

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

• कंपनीत त्यांच्या आगमनाचा क्रम;
• कर क्रमांक;
• पासपोर्टची संख्या आणि मालिका.

कधीकधी डेटाबेस डिझाइनर प्राथमिक की म्हणून नैसर्गिक की वापरतात, परंतु बहुतेकदा ते स्वतंत्रपणे वापरले जातात. शेवटी, रेकॉर्ड हटवले जाऊ शकतात, बदलले जाऊ शकतात आणि यासारखे.

मला असे वाटते की तुम्ही इंटरनेटवर कथा वाचल्या असतील जेव्हा बेलीफ एखाद्या व्यक्तीवर त्याच्या पूर्ण नावाचे कर्ज टांगतात? हे फक्त एक अद्वितीय की च्या संकल्पनेशी संबंधित आहे. बँका आणि बेलीफसाठी पूर्ण नाव आणि जन्माच्या वर्षाद्वारे एखाद्या व्यक्तीचा शोध घेणे खूप सोयीचे आहे. आणि 99% प्रकरणांमध्ये हे एखाद्या व्यक्तीला ओळखण्यासाठी पुरेसे आहे.

परंतु उर्वरित <1% पूर्ण नावे आहेत, जन्माच्या त्याच वर्षासह. आपल्यापैकी प्रत्येकाच्या आयुष्यात, बहुधा असे लोक नसतात, परंतु राष्ट्रीय स्तरावर आहेत. सर्वसाधारणपणे, जर तुम्ही सॉफ्टवेअर लिहित असाल किंवा डेटाबेस डिझाइन करत असाल, तर हे जाणून घेणे उपयुक्त आहे की हे देखील असू शकते.