Псевдоними

Промяна на имена на колони

Трябва да се справим и с имената на колоните. В противен случай повтаряме имената name и id, но те съдържат различни данни. От друга страна, има първата колона id и колоната employee_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 employee, task
WHERE emploee.id = task.emploee_id

И резултатът от тази заявка:

Страхотно, проблемът с неразбираемите имена на колони е успешно решен. Заявката стана малко дълга, но всичко е ясно в получената table. И без допълнителни колони.

Псевдоними на таблици

Понякога имената на таблиците са твърде дълги и заемат много място в заявката. Ето защо, създателите на SQL, за да подобрят четливостта, Howто в случая с колоните, предложиха възможност за указване на псевдоними на таблици.

Общата форма на псевдоними (псевдоними на таблици) е Howто следва:

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

Четливостта е намаляла леко, но това е така, защото имената на таблиците първоначално са бor прости и ясни. Може и да е така:

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 

И в този случай псевдонимите вече са полезни, нали? ;)

първичен ключ

И още една важна информация за масите. Помните ли, че имахме колона employee_id в tableта на задачите? С него посочихме идентификатора на служителя от tableта на служителите.

Ако искаме да направим препратка от една table към редовете на друга table, тогава препратената table трябва да има колона с ID, който също се нарича първичен ключ - PRIMARY KEY .

Най-често това е специално добавена колона, чийто тип стойност е int . Когато добавяте записи към table, SQL автоматично задава стойността на тази колона.

Тогава много неща са свързани с тези ключове:

• свързване на различни таблици една с друга;
• бързо търсене и филтриране по id;
• цялост на данните в базата данни (без препратки към несъществуващ идентификатор);
• изтриване на данни, на които никой не се позовава;
• и много много други.

Между другото, има ситуации, когато tableта има така наречения естествен ключ . Това е, когато има колона, чието съдържание предполага уникалност. Например решихме да добавим към tableта на служителите:

• Редът на пристигането им в компанията;
• Данъчен номер;
• Номер и серия на паспорта.

Понякога дизайнерите на бази данни използват естествен ключ като първичен ключ, но най-често те се използват отделно. В крайна сметка записите могат да бъдат изтривани, променяни и други подобни.

Предполагам, че четете истории в интернет, когато съдия-изпълнители висят дългове на пълния му съименник на човек? Това е просто свързано с концепцията за уникален ключ. За банките и съдебните изпълнители е много удобно да търсят човек по трите имена и година на раждане. И в 99% от случаите това е достатъчно, за да се идентифицира човек.

Но останалите <1% са пълни съименници, с една и съща година на раждане. В живота на всеки от нас най-вероятно няма такива хора, но в национален мащаб има. Като цяло, ако пишете софтуер or проектирате база данни, тогава е полезно да знаете, че това също може да бъде така.