Меняем названия колонок
Также нам нужно разобраться с названиями колонок. А то у нас повторяются названия name и id, а ведь они содержат различные данные. С другой стороны, есть первая колонка id и колонка employee_id, которые содержат одни и те же данные.
Давай напишем запрос, где будут только нужные колонки, а также переименуем колонки с одинаковыми именами:
SELECT task.id AS task_id, task.name AS task_desc, task.deadline AS deadline, employee.id AS employee_id, employee.name AS emp_name, employee.occupation AS emp_occupation FROM employee, task WHERE employee.id = task.employee_id И результат такого запроса:
| task_id | task_desc | deadline | employee_id | emp_name | emp_occupation |
|---|---|---|---|---|---|
| 1 | Исправить багу на фронтенде | 2022-06-01 | 1 | Иванов Иван | Программист |
| 2 | Исправить багу на бэкенде | 2022-06-15 | 2 | Петров Петр | Программист |
| 7 | Наслаждаться жизнью | (NULL) | 4 | Рабинович Мойша | Директор |
| 3 | Купить кофе | 2022-07-01 | 5 | Кириенко Анастасия | Офис-менеджер |
| 4 | Купить кофе | 2022-08-01 | 5 | Кириенко Анастасия | Офис-менеджер |
| 5 | Купить кофе | 2022-09-01 | 5 | Кириенко Анастасия | Офис-менеджер |
| 8 | Наслаждаться жизнью | (NULL) | 6 | Васька | кот |
Отлично, проблема с непонятными названиями колонок успешно решена. Запрос стал немного длинноватым, зато в результирующей таблице все понятно. И никаких лишних колонок.
Алиасы таблиц
Иногда названия таблиц бывают слишком длинными и занимают много места в запросе. Поэтому создатели SQL для повышения читабельности, как и в случае с колонками, предложили возможность указывать алиасы таблиц.
Общий вид алиасов (псевдонимов таблиц) такой:
FROM таблица1 псевдоним1, таблица2 псевдоним2
Давай перепишем наш предыдущий запрос с использованием коротких псевдонимов:
SELECT t.id AS task_id, t.name AS task_desc, t.deadline AS deadline, e.id AS employee_id, e.name AS emp_name, e.occupation AS emp_occupation FROM employee e, task t WHERE e.id = t.employee_id Читабельность немного снизилось, но это потому, что названия таблиц изначально были простыми и понятными. Может ведь быть и так:
SELECT task.id AS task_id, task.name AS task_desc, task.deadline AS deadline, employee.id AS employee_id, employee.name AS emp_name, employee.occupation AS emp_occupation FROM Microsoft_it_department_employee employee, Year2022_priority_task task WHERE employee.id = task.employee_id
А в этом случае алиасы уже полезны, да? ;)
Первичный ключ
И еще одна важная информация про таблицы. Помните, что у нас в таблице task была колонка employee_id? С ее помощью мы ссылались на ID сотрудника из таблицы employee.
Если мы хотим ссылаться из одной таблицы на строки другой таблицы, то таблица, на которую ссылаются, должна иметь колонку с ID, которую еще называют первичным ключом — PRIMARY KEY.
Чаще всего это специально добавленная колонка, тип значений которой — int. При добавлении записей в таблицу SQL автоматически устанавливает значение этой колонки.
На эти ключи потом много чего завязывается:
- связывание разных таблиц друг с другом;
- быстрый поиск и фильтрация по id;
- целостность данных в базе данных (нет ссылок на несуществующие id);
- удаление данных, на которые никто не ссылается;
- и многое многое другое.
Кстати, бывают ситуации, когда у таблицы есть так называемый натуральный ключ. Это когда есть колонка, содержимое которой подразумевает уникальность. Например, мы решили в таблицу сотрудников добавить:
- Порядок их прихода в компанию;
- Налоговый номер;
- Номер и серию паспорта.
Иногда проектировщики баз данных используют натуральный ключ в качестве первичного ключа, но чаще всего их используют раздельно. Записи ведь можно удалять, изменять и тому подобное.
Читали небось истории в интернете, когда на человека приставы вешают долги его полного тезки? Это как раз связано с понятием уникального ключа. Банкам и приставам очень удобно искать человека по ФИО и году рождения. И в 99% случаев этого достаточно для того, чтобы идентифицировать человека.
Но оставшийся <1% — это полные тезки, с одинаковым годом рождения. В жизни каждого из нас таких скорее всего нет, а вот в масштабах страны – есть. В общем если вы пишете софт или проектируйте БД, то полезно знать, что и так тоже может быть.