Modifica dei nomi delle colonne

Dobbiamo anche occuparci dei nomi delle colonne. Altrimenti, ripetiamo i nomi nome e id, ma contengono dati diversi. D'altra parte, c'è la prima colonna id e la colonna employee_id, che contengono gli stessi dati.

Scriviamo una query, dove ci saranno solo le colonne necessarie, e rinominiamo anche le colonne con gli stessi nomi:

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

E il risultato di questa query:

task_id task_desc scadenza impiegato_id emp_name emp_occupazione
1 Risolto un bug sul frontend 2022-06-01 1 Ivanov Ivan Programmatore
2 Risolto un bug sul backend 2022-06-15 2 Petrov Petr Programmatore
7 Goditi la vita (NULLO) 4 Rabinovich Moisha Direttore
3 Compra il caffè 2022-07-01 5 Kirienko Anastasia Capo ufficio
4 Compra il caffè 2022-08-01 5 Kirienko Anastasia Capo ufficio
5 Compra il caffè 2022-09-01 5 Kirienko Anastasia Capo ufficio
8 Goditi la vita (NULLO) 6 Vasca gatto

Fantastico, il problema con i nomi di colonna incomprensibili è stato risolto con successo. La query è diventata un po' lunga, ma tutto è chiaro nella tabella risultante. E nessuna colonna extra.

Alias ​​di tabella

A volte i nomi delle tabelle sono troppo lunghi e occupano molto spazio nella query. Pertanto, i creatori di SQL, per migliorare la leggibilità, come nel caso delle colonne, hanno offerto la possibilità di specificare alias di tabella.

La forma generale degli alias (alias di tabella) è la seguente:

FROM table1 alias1, table2 alias2

Riscriviamo la nostra query precedente con brevi alias:

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

La leggibilità è leggermente diminuita, ma questo perché i nomi delle tabelle erano inizialmente semplici e chiari. Potrebbe anche essere così:

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 

E in questo caso gli alias sono già utili, giusto? ;)

chiave primaria

E un'altra informazione importante sui tavoli. Ricordi che avevamo una colonna employee_id nella tabella delle attività? Con esso, abbiamo fatto riferimento all'ID dipendente dalla tabella dei dipendenti.

Se vogliamo fare riferimento da una tabella alle righe di un'altra tabella, la tabella di riferimento deve avere una colonna con un ID, che è anche chiamata chiave primaria - PRIMARY KEY .

Molto spesso, si tratta di una colonna aggiunta in modo speciale il cui tipo di valore è int . Quando si aggiungono record a una tabella, SQL imposta automaticamente il valore di questa colonna.

Quindi molte cose sono legate a queste chiavi:

  • collegare diverse tabelle tra loro;
  • ricerca rapida e filtraggio per id;
  • integrità dei dati nel database (nessun riferimento a id inesistenti);
  • cancellare i dati a cui nessuno fa riferimento;
  • e tanti tanti altri.

A proposito, ci sono situazioni in cui una tabella ha una cosiddetta chiave naturale . Questo è quando c'è una colonna il cui contenuto implica unicità. Ad esempio, abbiamo deciso di aggiungere alla tabella dei dipendenti:

  • L'ordine del loro arrivo in azienda;
  • codice fiscale;
  • Numero e serie del passaporto.

A volte i progettisti di database utilizzano una chiave naturale come chiave primaria, ma molto spesso vengono utilizzate separatamente. Dopotutto, i record possono essere cancellati, modificati e simili.

Suppongo che tu legga storie su Internet quando gli ufficiali giudiziari impiccano i debiti del suo omonimo completo su una persona? Questo è solo correlato al concetto di chiave univoca. È molto conveniente per banche e ufficiali giudiziari cercare una persona per nome completo e anno di nascita. E nel 99% dei casi questo è sufficiente per identificare una persona.

Ma il restante <1% sono omonimi completi, con lo stesso anno di nascita. Nella vita di ognuno di noi, molto probabilmente non ci sono persone del genere, ma su scala nazionale ci sono. In generale, se stai scrivendo un software o progettando un database, allora è utile sapere che può essere anche così.