Postgresql: UUID или SEQUENCE для первичного ключа?

Я прихожу из MySQL, а в MySQL вы можете использовать AUTOINCREMENT для уникального идентификатора строки в качестве первичного ключа.

Я обнаружил, что в Postgresql нет AUTOINCREMENT, только SEQUENCE или UUID. Я где-то читал, что мы можем использовать UUID в качестве первичного ключа таблицы. Это имеет дополнительное преимущество маскировки другого идентификатора пользователя (поскольку я хочу создавать API-интерфейсы, которые принимают ID в качестве параметра). Что я должен использовать для Postgresql?

Ответ 1

A sequence в PostgreSQL делает то же самое, что и AUTOINCREMENT в MySQL. A sequence более эффективен, чем a uuid, поскольку для uuid он равен 8 байтам вместо 16. Вы можете использовать uuid как первичный ключ, как и любой другой тип данных.

Однако я не вижу, как это относится к маскировке идентификатора пользователя. Если вы хотите скрыть идентификатор определенного пользователя от других пользователей, вы должны тщательно управлять привилегиями таблицы и/или шифровать идентификатор, используя - например - md5().

Если вы хотите защитить таблицу с пользовательскими данными от хакеров-хакеров, которые пытаются угадать другие идентификаторы, тип uuid является отличным выбором. Вариант 4 является лучшим выбором, так как он имеет 122 случайных бита (остальные 6 используются для идентификации версии). Вы можете создать первичный ключ следующим образом:

id uuid PRIMARY KEY DEFAULT uuid_generate_v4()

и тогда вам больше не придется беспокоиться об этом.

Ответ 2

Вы можете использовать UUID в качестве первичного ключа в вашей таблице, поскольку он будет уникальным. Однако имейте в виду, что UUID будет занимать немного больше места по сравнению с SEQUENCE. А также они не очень быстрые. Но да, они наверняка уникальны, и поэтому вы гарантированно получите непротиворечивые данные.

Вы также можете сослаться на:

Ответ 3

В течение многих лет я разрабатывал приложения для баз данных, используя PK и FK в качестве числовых последовательных значений. Это сработало отлично, но в последние годы, создавая облачные приложения, в которых информация будет обмениваться между приложениями, и у нас будет интеграция между различными разработанными нами приложениями, мы поняли, что использование последовательных идентификаторов в наших API привело к созданию усилий.

В некоторых приложениях мы должны найти идентификатор (целевого приложения) для отправки через вызов API, с другой стороны, в наших таблицах базы данных во всех наших приложениях, кроме последовательного столбца PK/FK, есть столбец UUID, который не был использован в вызовах API. В этом сценарии мы решили переписать API, чтобы был использован столбец UUID.

Это решило некоторые проблемы, поскольку одно из наших настольных приложений перенесло свои данные в другое облачное приложение, в этом облачном приложении также использовались столбцы PK/FK. При переносе этих данных мы должны были изменить значения PK/FK для новых последовательностей, поскольку последовательности могут конфликтовать между значениями приложения для настольного компьютера и значениями облачного приложения. Имея это в виду, мы решили переключить PK/FK облачного приложения на UUID, поскольку данные, поступающие из настольного приложения, имели столбец UUID.

Тогда проблема состояла в том, чтобы преобразовать таблицы облачных приложений, превратив столбцы INT (PK и FK) в столбцы UUID без потери информации таблицы. Это была большая задача, но ее стало проще, потому что я закончил создавать приложение, которое делает эти изменения более легкими. Приложение меняет каждый целочисленный столбец PK/FK на UUID, сохраняя данные и взаимосвязи. Любой заинтересованный переходит по ссылке:

https://claytonbonelli.github.io/int_pk2uuid_pk/