Является ли использование UUId в качестве pk хорошей идеей в микросервисах?

Я работаю над микросервисным проектом, который содержит 4 сервиса, разработанных на django. Я использую dj rest auth для обработки процесса входа и регистрации, каждый сервис имеет свою собственную базу данных и информация о пользователях хранится в сервисе account, а другие 3 сервиса получают информацию о пользователях через api запрос к сервису account, В каждом сервисе у меня есть доступ только к pk вошедшего пользователя (dj rest auth обрабатывает это) и когда мне нужно сохранить запись, например, местоположение вошедшего пользователя, я сохраняю объект пользователя, который содержит только pk и другую информацию, поэтому запись в базе данных будет выглядеть следующим образом: 

user=request.user(which saves logged in user but i only see the pk)
lat = latitue number
lng = longitude number

все хорошо, но если я потеряю базу данных сервиса account и восстановлю резервную копию, и каким-то образом записи создадут другой pk (например, перед восстановлением резервной копии будут добавлены новые записи), чем те, которые сохранены в других сервисах, что создает огромную проблему во всех сервисах. решение, которое я пробовал - изменить pk на uuid filed, но хорошая ли это идея? или может быть лучше добавить uuid filed к модели пользователя в базе данных account и в других сервисах сохранять этот uuid вместе с pk пользователя ?

Ответы на этот вопрос могут быть субъективными с разных точек зрения. Вот мое мнение на этот счет:

Там должно быть поле id типа INT, которое является первичным ключом с возможностью автоинкремента. Наряду с ним можно добавить поле UUID, скажем, uid.

Преимущества:

  1. Использование id в качестве первичного ключа делает вашу схему согласованной с остальными таблицами базы данных.
  2. Вы можете использовать поле id в качестве внешнего ключа, и это займет меньше места, чем UUID.
  3. В публичных URL вы можете использовать поле uid, и это не раскроет информацию, которую можно угадать. Например, если вы используете и id, а в URL id ресурса равен 5, то злоумышленник может догадаться, что может существовать ресурс с id 6, 7. Но используя поле uid, которое является полем UUID, вы не раскрываете информацию, связанную с базой данных.
Вернуться на верх