SQL - Составной ключ: Пособие для начинающих

Здравствуйте, будущие маги баз данных! Сегодня мы отправимся в увлекательное путешествие в мир SQL и рассмотрим концепцию, которая может показаться пугающей на первый взгляд, но на самом деле она довольно проста и incredibly полезна. Мы говорим о Составных ключах!

Что такое Составной ключ?

Прежде чем окунуться в深海, давайте начнем с азов. Представьте, что вы организовываете огромную библиотеку. Каждая книга должна иметь уникальный идентификатор, верно? Но что, если один только заголовок книги недостаточно, чтобы отличить ее? Вот где на помощь приходит наш герой, Составной ключ!

Составной ключ — это как командное объединение супергероев в мире баз данных. Это комбинация двух или более столбцов, которая вместе уникально идентифицирует строку в таблице. Это как сказать: "Эта книга уникальна благодаря своему заголовку И автору И году издания."

Why Use Composite Keys? (Почему использовать Составные ключи?)

1. Уникальность: Они обеспечивают истинную уникальность каждой строки в вашей таблице.
2. Целостность данных: Они помогают поддерживать точность и一致性 ваших данных.
3. Создание отношений: Они великолепны для создания связей между таблицами.

Теперь давайте натянем рукава и脏 our hands с некоторыми кодами!

Создание Составного ключа

Давайте создадим таблицу для нашей вымышленной библиотеки:

CREATE TABLE books (
title VARCHAR(100),
author VARCHAR(50),
publication_year INT,
ISBN VARCHAR(13),
PRIMARY KEY (title, author, publication_year)
);

В этом примере мы создали составной ключ, используя столбцы title, author и publication_year. Это означает, что две книги не могут иметь одну и ту же комбинацию этих трех атрибутов.

Ввод данных с Составными ключами

Давайте добавим несколько книг в нашу библиотеку:

INSERT INTO books (title, author, publication_year, ISBN)
VALUES ('Великий Гэтсби', 'Ф. Скотт Фицджеральд', 1925, '9780743273565'),
('Убить пересмешника', 'Harper Lee', 1960, '9780446310789'),
('1984', 'Джордж Оруэлл', 1949, '9780451524935');

Эти вставки будут работать нормально, потому что каждая комбинация заголовка, автора и года издания уникальна.

Но что happens if мы пытаемся вставить дубликат?

INSERT INTO books (title, author, publication_year, ISBN)
VALUES ('Великий Гэтсби', 'Ф. Скотт Фицджеральд', 1925, '1234567890123');

Ой! Это вызовет ошибку, потому что у нас уже есть книга с exact заголовком, автором и годом издания. Наш составной ключ выполняет свою работу!

Запросы с Составными ключами

При запросе таблицы с составным ключом вам часто нужно указать все части ключа:

SELECT * FROM books
WHERE title = 'Великий Гэтсби'
AND author = 'Ф. Скотт Фицджеральд'
AND publication_year = 1925;

Этот запрос вернет exact книгу, которую мы ищем.

Удаление Составного ключа

Теперь, что если мы решим, что наш составной ключ больше не работает для нас? Возможно, мы поняли, что ISBN на самом деле является лучшим уникальным идентификатором для наших книг. Давайте посмотрим, как удалить составной ключ в различных системах баз данных.

Удаление Составного ключа в MySQL

В MySQL удаление составного ключа довольно просто:

ALTER TABLE books
DROP PRIMARY KEY;

После удаления ключа мы можем добавить новый primary key, если хотим:

ALTER TABLE books
ADD PRIMARY KEY (ISBN);

Удаление Составного ключа в SQL Server

SQL Server следует аналогичному шаблону:

ALTER TABLE books
DROP CONSTRAINT PK_books;

Здесь PK_books — это имя ограничения primary key. Если вы не уверены в имени ограничения, вы можете найти его, используя:

SELECT name
FROM sys.key_constraints
WHERE type = 'PK' AND parent_object_id = OBJECT_ID('books');

Затем, как и в MySQL, мы можем добавить новый primary key:

ALTER TABLE books
ADD CONSTRAINT PK_books PRIMARY KEY (ISBN);

Составные ключи против Одноколоночных ключей

Теперь вы можете задаться вопросом: "Зачем беспокоиться о составных ключах, если я могу просто использовать один столбец?" Отличный вопрос! Давайте разберем это:

Aspect	Составные ключи	Одноколоночные ключи
Уникальность	Обеспечивают уникальность по нескольким атрибутам	Ограничены уникальностью одного атрибута
Гибкость	Более гибкие в представлении сложных отношений	Проще, но могут не captures все необходимые данные
производительность запроса	могут быть медленнее для индексации и запросов	Обычно быстрее для индексации и запросов
Целостность данных	могут обеспечивать более сложные бизнес-правила	Проще в поддержке
хранилище	могут требовать больше места для хранения	Обычно требуют меньше места для хранения

Заключение

Итак, дорогие друзья! Мы отправились в путешествие по стране Составных ключей, от создания до запросов и удаления. Помните, как и любое средство в вашем SQL арсенале, составные ключи имеют свое время и место. Они великолепны для обеспечения уникальности по нескольким столбцам и представления сложных отношений, но они могут не всегда быть лучшим выбором для каждой ситуации.

Пока вы продолжаете свое путешествие в мир SQL, продолжайте экспериментировать с различными структурами ключей. Чем больше вы практикуетесь, тем более интуитивно это станет. И кто знает? Возможно,有一天, вы будете объяснять составные ключи новомуbatch из увлеченных студентов!

До свидания, счастливого кодирования, и пусть ваши запросы всегда возвращают те результаты, которые вы ищете!

Credits: Image by storyset