Нужен ли первичный ключ в таблицах 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

[mrfreeman2]

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