Ответ
В реляционных СУБД для организации данных и обеспечения их целостности используются несколько типов ключей:
-
Primary Key (PK, Первичный ключ) — уникальный идентификатор записи в таблице. Он не может содержать
NULLи должен быть абсолютно уникальным. Используется для прямой идентификации и быстрого доступа к строке. -
Foreign Key (FK, Внешний ключ) — ключ в одной таблице, который ссылается на
PRIMARY KEYв другой. Он обеспечивает ссылочную целостность между таблицами, предотвращая создание записей, ссылающихся на несуществующие данные. -
Unique Key (Уникальный ключ) — гарантирует, что все значения в столбце (или наборе столбцов) уникальны. В отличие от PK, может содержать одно значение
NULL(в большинстве СУБД). Часто используется для полей, которые должны быть уникальными, но не являются основным идентификатором (например, email пользователя). -
Composite Key (Составной ключ) — первичный ключ, состоящий из двух или более столбцов. Используется, когда уникальность записи можно определить только комбинацией значений (например, в связующей таблице
user_rolesключом будет параuser_idиrole_id). -
Candidate Key (Потенциальный ключ) — любой столбец или набор столбцов, который может служить первичным ключом (т.е. он уникален и не
NULL). Таблица может иметь несколько потенциальных ключей, один из которых выбирается как первичный.
Пример в SQL:
-- Таблица команд
CREATE TABLE teams (
id INT PRIMARY KEY,
name VARCHAR(100) NOT NULL UNIQUE
);
-- Таблица пользователей с внешним и уникальным ключами
CREATE TABLE users (
id INT PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL, -- Уникальный ключ
team_id INT,
FOREIGN KEY (team_id) REFERENCES teams(id) -- Внешний ключ
);Ответ 18+ 🔞
О, ключи в базах данных, ну это вообще отдельная песня, блядь! Сидишь ты такой, думаешь: "Ну табличка, ну данные, хуйня вопрос". А нихуя! Тут целая наука, чтобы всё не разъехалось и не превратилось в кашу, где ни хуя не найти.
Смотри, есть у нас главный пахан — Первичный ключ (Primary Key). Это типа татуха на зоне, уникальная, блядь. У каждой записи в таблице она своя, и больше ни у кого такой нет. NULL туда не суй — сразу пиздец, ошибка. По нему сразу находишь нужного зека, то есть строку.
А дальше начинается магия связей. Вот есть Внешний ключ (Foreign Key). Это как наш зек из одной камеры получает передачку из другой, но только если там реально есть тот, кто её отправил. То есть запись в одной таблице ссылается на первичный ключ в другой. Нет там записи — и ссылаться нехуй, система не даст. Это и есть ссылочная целостность, чтобы не было сирот-записей, которые в пустоту смотрят.
А бывает, что первичный ключ — он один, но есть другие поля, которые тоже должны быть уникальными. Ну, например, почта юзера. Для этого Уникальный ключ (Unique Key). Он почти как первичный, но не главный. И NULL иногда может простить один разок, в отличие от нашего строгого пахана-PK.
Теперь, хуле, если одной татухи мало, чтобы уникальность обеспечить? Бывает же, что только пара признаков вместе дают уникальность. Вот, например, таблица, кто какую роль в проекте имеет: user_id и project_id. По отдельности — повторения, а вместе — уникальная хуйня. Это Составной ключ (Composite Key). Два ствола лучше, чем один, блядь.
И наконец, Потенциальный ключ (Candidate Key). Это типа все кандидаты на пост главного пахана (PK). Столбец или даже группа столбцов, которые могли бы им стать — уникальные и без NULL. А ты из них одного выбираешь королём, а остальные в уникальные ключи идут. Вся жизнь — выбор, ёпта.
Вот смотри, как это в коде выглядит, блядь:
-- Таблица команд
CREATE TABLE teams (
id INT PRIMARY KEY, -- Вот он, главный по тарелкам, первичный ключ
name VARCHAR(100) NOT NULL UNIQUE -- А name тоже уникальный, но не главный
);
-- Таблица пользователей
CREATE TABLE users (
id INT PRIMARY KEY, -- Опять царь и бог строки
email VARCHAR(255) UNIQUE NOT NULL, -- Уникальный ключ, почта чтоб не повторялась, а то пиздец начнётся
team_id INT, -- Это поле будет ссылаться на команду
FOREIGN KEY (team_id) REFERENCES teams(id) -- Внешний ключ! Смотри, team_id теперь в цепях. Нет такой команды в teams — пользователя не создать. Порядок, блядь.
);Вот и вся философия. Сначала кажется, что заебали с этими ключами, а потом, когда данные не превращаются в говносвалку, понимаешь — а они были правы, суки.