Нужен ли первичный ключ в таблицах PostgreSQL?

Question

[shupike]

Добрый день! Такой вопрос - пытаюсь старую базу MS Access перевести в PostgreSQL (тупо руками пересоздаю таблицы и поля) и вот что не понял - у меня есть таблица в MS Access без ключевого поля, то есть просто служит для связанности при запросах. Я создал аналогичную таблицу в pgadmin, но вносить в нее данные без первичного ключа не удается. Получается, что нужно добавить в любом случае поле первичного ключа и вручную потом отслеживать его значение при добавлении/удалении записей в этой таблице? А почему все это работает без первичного ключа в MS Access? Спасибо.

Comments

[Akina]

просто служит для связанности при запросах

?? Что означает эта фраза? Если речь об организации связи M:N, то да, без ПК тут можно и пережить... и в Постгрессе, кстати, тоже. Хотя куцего описания явно недостаточно, чтобы понять происходящее.

Answer 1

[Сергей Соловьев]

Почему работает в Access - потому что это другая БД. Поведение может различаться.

Что касается обязательности ключевого поля - странно. Таблицу можно создать и без него.

Предполагаю, что эта таблица ссылается через references на столбец другой таблицы. В таком случае, на последнее должно стоять ограничение уникальности - иначе как понять на какую строку ссылаться.

Comments

[shupike]

Да, таблица создается. Но когда я пытаюсь вручную добавить данные через pgadmin - кнопка добавления неактивна. Вот догадался добавить первичный ключ - но вообще это лишнее, как мне кажется. Может быть, попробовать через INSERT INTO прямо в ssh-консоли PostgreSQL-сервера? У меня на Ubuntu собран.

[Melkij]

ограничивает именно ваш используемый клиент.

таблицы без первичного ключа в большинстве случаев это ошибка разработчика схемы данных. Но в остальном обычная табличка, может так и существовать в postgresql без первичного ключа.

[Сергей Соловьев]

shupike, проверь обязательные поля, например название таблицы - возможно их не хватает

[shupike]

Вот так это выглядит, если удалить pkey - просто блокируется кнопка Add.

[Akina]

shupike,

если удалить pkey - просто блокируется кнопка Add

А это может быть фича клиента.. вот запросто.

[Сергей Соловьев]

shupike, просто добавь суррогатный первичный ключ - generated always as identity если тебе он не нужен

[shupike]

Akina, И ведь таки да:



и проверил через клиента - запись добавилась. Ну я упростил пока - просто от балды поле придумал типа integer и рандомное значение вписал. Получается, это pgadmin кривой.

[Akina]

Получается, это pgadmin кривой.

Да нет, не сказать что кривой. Просто у его автора есть некое вИдение, как оно должно быть - и обязательность наличия ПК в таблице в этом вИдении присутствует.

И да, с точки зрения визуального клиента такая фича оправдана. Он обязан сохранять однозначное соответствие между физической записью в таблице и её отображением на экране... а как это сделать, если структура таблицы позволяет создать полные дубликаты? сервер-то их различит по некоему внутреннему индексу, а что делать бедному клиенту?
А если начхать на идентификацию, типа поправим любой из дубликатов, какая разница, то таким подходом можно капитально нагадить в параллельную транзакцию.

[shupike]

А есть альтернативный GUI-клиент для редактирования таблиц? Ну понятно, что можно через putty таблицы наполнить вручную, но все же :-)

[Slava Rozhnev]

shupike, DBeaver

[shupike]

Набил пока через ssh таблицу, через pgadmin видно, что добавляется какой-то счетчик строк, показывается только в pgadmin, без имени. Видимо, это сам клиент временно добавляет при запросе к таблице. В общем-то, разобрался - всем спасибо за поддержку :-)

Answer 2

[Виктор Кожухарь]

Вот пример создания таблицы point_user из одного из моих проектов, которая состоит из двух полей, связывающих две другие таблицы (point и user) отношениями many-to-many. В этих двух полях содержатся id записей из тех двух таблиц. Первичный ключ тут просто составной, состоящий из обоих полей. И не надо его как-то специально отслеживать.

create table point_user
(
    point_id uuid not null
        constraint fk_413312bc028cea2
            references point
            on delete cascade,
    user_id  uuid not null
        constraint fk_413312ba76ed395
            references "user"
            on delete cascade,
    primary key (point_id, user_id)
);

create index idx_413312ba76ed395
    on point_user (user_id);

create index idx_413312bc028cea2
    on point_user (point_id);

Comments

[Akina]

А нафига нужен отдельный индекс по point_id?

[Виктор Кожухарь]

Akina, Хороший вопрос))
Но вопрос автора был не в индексе. Тут пример, как можно и иметь primary key в такой таблице, где устанавливается связь между двумя таблицами, и не городить при этом отдельное поле для этого primary key

[Akina]

Виктор Кожухарь, обычно в связующей таблице (adjacency table) создают прямой и обратный индексы (в вашем случае (point_id, user_id) и соответственно (user_id, point_id)). Они накрывают любое использование этой таблицы. Ну и либо один из них объявляется первичным, либо добавляется синтетический ПК (если сама связь по модели является сущностью), и тогда поля явно описываются как NOT NULL и один либо оба индекса делаются уникальными.

[shupike]

Попутно еще хотел спросить - допустим, я вручную через psql в консоли добавлю все строки в этой таблице, но вот еще одно отличие от MS Access - там если поле длиной 50 символов (char), то в случае с PostgreSQL автоматически не срезаются пробелы в конце. Чтобы было понятнее - GUI, который работает с базой - при подключении к нему базы на Postgre оставляет пустые символы по каждой строке. На MS Access все подгонялось под фактическую длину поля. То есть если занято 23 символами, висит пустота правее в 27 пробелов. Это никак не победить?

[Виктор Кожухарь]

shupike, База хранит то, что вы в неё пишете. Всяким обрезанием/вставкой пробелов и т.д. занимаются клиенты базы: а именно GUI, фронтенды, бэкенды и прочие "вредители"

Answer 3

[mrfreeman2]

Первичный ключ — это свойства строки, которые однозначно идентифицируют эту запись.
Первичное значение — не обязательно 1 поле, и не обязательно придумывать новое поле, вероятнее всего, то, что есть уже достаточно, и ключ можно составить из того, что есть.
Под капотом первичный индекс — это такой же индекс, но значения в нем уникальны и не могут быть null.
В целом без первичного ключа можно, но первичный ключ нужен для реплицирования данных, для миграции данных при обновлении версии pg и банально для предотвращения появления дублей записи. Итог: лучше его иметь, чем не иметь.