Aliasuri

Modificarea numelor coloanelor

De asemenea, trebuie să ne ocupăm de numele coloanelor. În caz contrar, repetăm ​​numele nume și id, dar acestea conțin date diferite. Pe de altă parte, există prima coloană id și coloana employee_id, care conțin aceleași date.

Să scriem o interogare, în care vor fi doar coloanele necesare și, de asemenea, să redenumim coloanele cu aceleași nume:

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

Și rezultatul acestei interogări:

Grozav, problema cu numele coloanelor de neînțeles a fost rezolvată cu succes. Interogarea a devenit puțin lungă, dar totul este clar în tabelul rezultat. Și fără coloane suplimentare.

Aliasuri de tabel

Uneori, numele tabelelor sunt prea lungi și ocupă mult spațiu în interogare. Prin urmare, creatorii SQL, pentru a îmbunătăți lizibilitatea, ca și în cazul coloanelor, au oferit posibilitatea de a specifica aliasuri de tabel.

Forma generală a alias-urilor (alias-uri de tabel) este următoarea:

FROM table1 alias1, table2 alias2

Să rescriem interogarea anterioară cu pseudonime scurte:

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

Lizibilitatea a scăzut ușor, dar acest lucru se datorează faptului că numele tabelelor au fost inițial simple și clare. Ar putea fi la fel de bine așa:

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 

Și în acest caz, pseudonimele sunt deja utile, nu? ;)

cheia principala

Și încă o informație importantă despre tabele. Vă amintiți că aveam o coloană employee_id în tabelul de activități? Cu acesta, am făcut referire la ID-ul angajatului din tabelul angajaților.

Dacă vrem să ne referim dintr-un tabel la rândurile altui tabel, atunci tabelul la care se face referire trebuie să aibă o coloană cu un ID, care se mai numește și cheie primară - CHEIE PRIMARĂ .

Cel mai adesea, aceasta este o coloană special adăugată al cărei tip de valoare este int . Când adăugați înregistrări la un tabel, SQL setează automat valoarea acestei coloane.

Apoi, multe lucruri sunt legate de aceste chei:

• legarea diferitelor tabele între ele;
• căutare rapidă și filtrare după id;
• integritatea datelor în baza de date (fără referiri la id inexistent);
• ștergerea datelor la care nimeni nu se referă;
• si multi multi altii.

Apropo, există situații în care un tabel are o așa-numită cheie naturală . Acesta este momentul în care există o coloană al cărei conținut implică unicitate. De exemplu, am decis să adăugăm la tabelul angajaților:

• Ordinea sosirii lor în companie;
• Cod fiscal;
• Numărul și seria pașaportului.

Uneori, designerii de baze de date folosesc o cheie naturală ca cheie primară, dar cel mai adesea sunt folosite separat. La urma urmei, înregistrările pot fi șterse, modificate și altele asemenea.

Presupun că ai citit povești pe internet când executorii judecătorești atârnă datoriile omonimului său complet pe o persoană? Acest lucru este legat doar de conceptul de cheie unică. Este foarte convenabil pentru bănci și executori judecătorești să caute o persoană după numele complet și anul nașterii. Și în 99% din cazuri acest lucru este suficient pentru a identifica o persoană.

Dar restul de <1% sunt omonimi întregi, cu același an de naștere. În viața fiecăruia dintre noi, cel mai probabil nu există astfel de oameni, dar la scară națională există. În general, dacă scrieți software sau proiectați o bază de date, atunci este util să știți că acesta poate fi și cazul.