лучшая практика для ограничений первичного ключа? - PullRequest
0 голосов
/ 26 мая 2019

Интересно, что будет лучше в базе данных postgresql при использовании первичных ключей.

ЕСЛИ есть таблица с двумя столбцами UUID, такими как user1 и user2, что было бы лучше, использовать ключ ограничения или простоопределить оба столбца как уникальные без какого-либо первичного ключа, потому что в postgresql вы можете иметь только один первичный ключ в таблице?

Пример:

CREATE TABLE user_relation(
    sender_user_id UUID NOT NULL,
    receiver_user_id UUID NOT NULL,
    status INT NOT NULL,
    chat_id BIGINT,
    UNIQUE (chat_id),
    CONSTRAINT user_relation_pk UNIQUE(sender_user_id, receiver_user_id)

Или было бы лучше просто определитьоба «первичных ключа» как уникальные значения, как это?

CREATE TABLE user_relation(
    sender_user_id UUID NOT NULL,
    receiver_user_id UUID NOT NULL,
    status INT NOT NULL,
    chat_id BIGINT,
    UNIQUE (sender_user_id, receiver_user_id, chat_id)
)

1 Ответ

0 голосов
/ 27 мая 2019

Ваши два определения таблиц совершенно разные.

UNIQUE(a, b, c)

означает , а не означает, что каждый из этих столбцов будет уникальным, но комбинация всех трех будет уникальной (то есть вы не можете иметь одну и ту же тройку в таблице дважды).

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

В отличие от многих других, я не верю, что всегда необходимо вводить искусственный первичный ключ. Пока вы уверены, что

  1. выбранные столбцы чувствуются как & ldquo; хорошее представление & rdquo; данных.

  2. значение столбца (-ов) никогда не изменится

Не вижу проблем с использованием этого в качестве первичного ключа.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...