Псевдоніми

1. Змінюємо назви колонок

Також нам потрібно розібратися із назвами колонок. Зараз у нас повторюються назви 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.< span class="text-green">emploee_id

І результат такого запиту:

Чудово, проблему з незрозумілими назвами колонок успішно вирішено. Запит став трохи довгим, зате в результуючій таблиці все зрозуміло. І жодних зайвих стовпчиків.

2. Аліаси таблиць

Іноді назви таблиць бувають надто довгими і займають багато місця у запиті. Тому творці SQL для підвищення читабельності, як і у випадку з колонками, запропонували можливість вказувати аліаси таблиць.

Загальний вид аліасів (псевдонімів таблиць) такий:

FROM таблиця1 псевдонім1, таблиця2 псевдонім2

Давай перепишемо наш попередній запит із використанням коротких псевдонімів:

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 

А в цьому випадку аліаси вже корисні, так? ;)

3. Первинний ключ

І ще одна важлива інформація про таблиці. Пам'ятаєш, що в нас у таблиці task була колонка employee_id? За допомогою неї ми посилалися на ID співробітника з таблиці employee.

Якщо ми хочемо посилатися з однієї таблиці на рядки іншої таблиці, то таблиця, на яку посилаються, повинна мати колонку з ID, яку ще називають первинним ключем — PRIMARY KEY.

Найчастіше це спеціально додана колонка, тип значень якої — int. При додаванні записів до таблиці SQL автоматично встановлює значення цієї колонки.

На ці ключі потім багато чого зав'язується:

• зв'язування різних таблиць одна з одною;
• швидкий пошук та фільтрація за id;
• цілісність даних у базі даних (немає посилань на неіснуючі id);
• видалення даних, на які ніхто не посилається;
• і багато іншого.

До речі, бувають ситуації, коли таблиця має так званий натуральний ключ. Це коли є колонка, вміст якої є унікальним. Наприклад, ми вирішили до таблиці співробітників додати:

• Порядок їхнього приходу в компанію;
• Податковий номер;
• Номер та серію паспорта.

Іноді проєктувальники баз даних використовують натуральний ключ як первинний, але найчастіше їх використовують окремо. Адже записи можна видаляти, змінювати тощо.

Читали, мабуть, історії в інтернеті, коли на людину пристави вішають борги її повного тезки? Це пов'язано з поняттям унікального ключа. Банкам і приставам дуже зручно шукати людину за ПІБ та роком народження. І у 99% випадків цього достатньо для того, щоб ідентифікувати людину.

Але залишився <1% — це повні тезки, з однаковим роком народження. У житті кожного з нас таких, швидше за все, немає, а от у масштабах країни — є. Загалом, якщо ти пишеш софт або проєктуєш БД, корисно знати, що і так теж може бути.