Какие ключи бывают в PostgreSQL

Что проверяют

Различаете ли вы ключ как ограничение целостности и индекс как средство ускорения, и знаете ли, как это описывается в EF Core. Следом обычно спрашивают про поведение внешнего ключа при удалении и про суррогатный ключ против натурального.

Как отвечать

• первичный ключ: PRIMARY KEY, по сути UNIQUE плюс NOT NULL, один на таблицу, может быть составным. PostgreSQL сам создаёт под него уникальный B-tree индекс. Для автоинкремента в новых схемах берут GENERATED ... AS IDENTITY, SERIAL считается устаревшим способом. Npgsql-провайдер EF Core для целочисленных ключей по умолчанию создаёт identity-колонки;
• внешний ключ: REFERENCES, ссылается на первичный или любой уникальный ключ другой таблицы. Поведение при удалении задаёт ON DELETE: NO ACTION по умолчанию, RESTRICT, CASCADE, SET NULL, SET DEFAULT. Индекс на ссылающейся колонке PostgreSQL сам не создаёт;
• уникальный ключ: UNIQUE, тоже бывает составным. Несколько NULL по умолчанию допускаются, потому что NULL не равен NULL; с PostgreSQL 15 это меняется опцией NULLS NOT DISTINCT;
• естественный и суррогатный: ИНН или email против id или uuid. Суррогатный не меняется вместе с бизнес-данными, а естественный стоит закрыть уникальным ограничением;
• исключающее ограничение: EXCLUDE USING gist, например запрет пересекающихся бронирований.

В EF Core: HasKey для первичного и составного ключа, HasAlternateKey для уникального ключа, на который ссылаются связи, HasIndex(...).IsUnique() для уникального индекса, OnDelete(DeleteBehavior.Cascade) для правила удаления.

Где спотыкаются

Говорят, что уникальный ключ допускает только один NULL. Это поведение SQL Server, в PostgreSQL их может быть сколько угодно.

Считают, что внешний ключ индексируется автоматически. Без индекса удаление родителя и соединения по ссылке сканируют дочернюю таблицу целиком.

Называют индекс видом ключа. Индекс ускоряет поиск, ключ задаёт правило для данных, и на собеседовании по базам путать их дорого.