Мое приложение должно синхронизироваться с другими пользователями приложения (на собственных устройствах). Я также хочу поддерживать автономное редактирование, которое синхронизируется с другими совместными пользователями, когда пользователь подключается к Интернету.

Таким образом, пользователь А изменяет (пока он не в сети) некоторые данные (другими словами, он обновляет записи базы данных) или добавляет новые записи в базу данных. Когда пользователь А подключается к Интернету, все изменения и новые записи доставляются другим совместным пользователям. Таким образом, пользователь B получит изменения / обновления и может вставить / обновить их в базу данных локальных устройств пользователя B.

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

Мой вопрос: это плохая идея использовать UUID (String / Varchar) в качестве первичного ключа в таблице базы данных android sqlite вместо целого числа, которое будет автоматически увеличено?

Я предполагаю, что будут проблемы с производительностью при использовании строк (UUID имеет 36 символов) в качестве первичного ключа.

Я предполагаю, что индексирование uuids вместо целых занимает больше времени (сравнение строки и сравнения целых чисел). Я также предполагаю, что когда я использую UUID, каждый раз, когда вставляется новая запись / запись базы данных, базе данных необходимо переиндексировать столбец первичного ключа, поскольку индекс первичного ключа уже не в отсортированном порядке (что было бы, когда я использовал бы целочисленный автоинкрементный первичный ключ, потому что каждая будущая запись добавляется в конце, потому что новый автоинкрементный первичный ключ до сих пор всегда является наибольшим числом, поэтому индекс будет автоматически в отсортированном порядке). Что мне также нужно сделать, это СОЕДИНЯЕТСЯ за 2-3 столами. Я также предполагаю, что сравнение строк в JOINS вместо целых будет замедлять запрос к базе данных.

Однако я не вижу никакой другой возможности реализовать такую систему совместной синхронизации, поэтому я должен использовать UUID, верно?

Другой возможностью было бы использование целочисленного первичного ключа с автоинкрементом и использование второго столбца uuid. Поэтому для работы на локальном устройстве пользователя я бы использовал этот первичный ключ (целое число) для JOINS и т. Д., В то время как я использовал бы столбец uuid для синхронизации с другими пользователями.

Что вы, ребята, думаете об этом подходе или, по вашему мнению, очень много работы, поскольку вы не ожидаете значительных проблем с производительностью, используя UUID непосредственно в качестве первичного ключа?

Любые другие предложения?