Может ли Primary Key быть Null?

Может ли Primary Key быть NULL?

Нет, в реляционных базах данных значение Primary Key (первичного ключа) не может быть NULL. Это одно из фундаментальных и обязательных свойств первичного ключа, определяемое его назначением и закрепленное стандартами SQL и реализацией во всех основных СУБД (MySQL, PostgreSQL, Oracle, SQL Server и т.д.).

Ключевые свойства Primary Key и роль NULLability

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

1. Уникальность (UNIQUE): Каждое значение в столбце (или комбинации столбцов), выбранном в качестве первичного ключа, должно быть уникальным в пределах таблицы.
2. NOT NULL: Ни одно из значений первичного ключа не может быть неопределенным, то есть NULL. Это требование вытекает напрямую из первого.

Почему это так важно?

• Обеспечение идентифицируемости записей. Основная задача PRIMARY KEY — однозначно идентифицировать каждую строку в таблице. Значение NULL по определению означает "неизвестное" или "отсутствующее" значение. Две строки с NULL в ключевом поле не могут быть различимы, что нарушает принцип уникальной идентификации.
• Целостность ссылок (Referential Integrity). Первичный ключ является целевым для внешних ключей (FOREIGN KEY) из других таблиц. Механизм ссылочной целостности требует, чтобы каждое значение внешнего ключа соответствовало существующему и точно определенному значению первичного. Если бы первичный ключ мог быть NULL, это создало бы логическую несостоятельность: на что именно ссылается внешний ключ со значением, допустим, 101, если в родительской таблице есть запись с PK = 101, но также могут быть записи с PK = NULL? Это разрушило бы всю модель отношений.
• Стандарт SQL и реализация СУБД. Стандарт ANSI/ISO SQL прямо запрещает NULL в первичном ключе. Все СУБД следуют этому правилу на уровне системы. Попытка создать таблицу с nullable-полем в качестве первичного ключа или вставить/обновить запись с NULL в таком поле приведет к явной ошибке.

Практическая демонстрация

Рассмотрим на примере PostgreSQL. Попытка создать таблицу с PRIMARY KEY, допускающим NULL, завершится ошибной еще на этапе определения схемы.

-- НЕКОРРЕКТНО: СУБД не позволит этого сделать
CREATE TABLE employees (
    id INTEGER NULL PRIMARY KEY, -- Явное указание NULL избыточно и приведет к ошибке
    name VARCHAR(100) NOT NULL
);

Более реалистичный сценарий — попытка вставить NULL в уже существующий первичный ключ:

-- Корректное создание таблицы
CREATE TABLE employees (
    id INTEGER PRIMARY KEY, -- NOT NULL подразумевается автоматически
    name VARCHAR(100) NOT NULL
);

-- Успешная вставка
INSERT INTO employees (id, name) VALUES (1, 'Иван Петров');

-- ОШИБКА: нарушает ограничение NOT NULL для первичного ключа "employees_pkey"
INSERT INTO employees (id, name) VALUES (NULL, 'Аноним Анонимус');

При выполнении второй вставки СУБД вернет ошибку, подобную: ERROR: null value in column "id" violates not-null constraint

Важное отличие от Unique Constraint

Часто возникает путаница между PRIMARY KEY и UNIQUE CONSTRAINT. Вот ключевое различие:

• PRIMARY KEY = UNIQUE + NOT NULL. Таблица может иметь только один первичный ключ.
• UNIQUE CONSTRAINT гарантирует только уникальность, но может допускать NULL значения (в зависимости от СУБД, чаще всего — один NULL на столбец, так как NULL не считается равным другому NULL при сравнении). Таблица может иметь несколько уникальных ограничений.

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email VARCHAR(255) UNIQUE, -- Может содержать NULL (одна запись с email = NULL)
    username VARCHAR(100) NOT NULL UNIQUE
);

-- Это может быть допустимо (зависит от СУБД, в стандарте SQL - допустимо):
INSERT INTO users (id, email, username) VALUES (1, NULL, 'ivan');
INSERT INTO users (id, email, username) VALUES (2, NULL, 'petr'); -- В некоторых СУБД (например, PostgreSQL) это вызовет ошибку уникальности.

Итог

Таким образом, запрет на NULL в первичном ключе — это не просто техническое ограничение, а краеугольный камень реляционной модели, обеспечивающий:

• Гарантированную уникальную идентификацию каждой строки.
• Надежную основу для межтабличных связей через внешние ключи.
• Логическую целостность и предсказуемость данных.

Любой опытный инженер или разработчик, работающий с базами данных, должен четко понимать и разъяснять это правило как аксиому.