Есть поле, являющееся первичным ключом. Это поле не должно содержать «нулевых» значений.
Есть ли необходимость в NOT NULL, или достаточно только PRIMARY KEY?
Ответ
У уникальных полей есть одна забавная особенность. Уникальность определяется равенством. Но NULL не равен NULL! Поэтому значения NULL можно добавлять в столбец с проверкой на уникальность в любом количестве строк!
А первичный ключ должен уникально идентифицировать каждую строку по равенству значения этого ключа. Потому значение NULL для первичного ключа не имеет смысла. При сравнении равенством он просто никогда не совпадёт ни с какой строкой.
Это распространяется на все SQL-совместимые базы данных.
Но процитирую определение первичного ключа с dev.mysql.com
A set of columns—and by implication, the index based on this set of columns—that can uniquely identify every row in a table. As such, it must be a unique index that does not contain any NULL values.
Набор столбцов и индекс по этому набору столбцов, способный однозначно идентифицироать каждую строку в таблице. Это уникальный индекс, не содержащий значений NULL
Так что да, PRIMARY KEY требует, чтобы его столбцы были NOT NULL
И в зависимости от того, каким синтаксисом определяется первичный ключ, указание NOT NULL может быть обязательным или необязательным. В MySQL (по всей видимости) обязательно всегда.
Синтаксис определения первичного ключа я встречал трёх видов:
Прямо при определении типа колонки, добавив PRIMARY KEY к её типу:
CREATE TABLE things ( id integer PRIMARY KEY )
Указание NOT NULL может быть необязательным. Но в MySQL, судя по примерам (документация не особо помогла), обязательно. В PostgreSQL же нет: там считается, что PRIMARY KEY в типе столбца включает в себя NOT NULL
При определении первичного ключа в составе определения таблицы (но не её :столбцов)
CREATE TABLE things ( id integer NOT NULL, PRIMARY KEY(id) )
NOT NULL обязательно, иначе упоминание колонки в PRIMARY KEY будет конфликтовать с уже объявленным.
При определении первичного ключа на уже созданной таблице отдельно.
NOT NULL обязательно, т. к. таблица уже определена.
Комментариев нет:
Отправить комментарий