Android：SQLiteの主キーとしてUUIDを使用する
私のアプリは他のアプリユーザーと同期する必要があります（自分のデバイス上で）。また、ユーザーがインターネットに接続したときに他の共同作業ユーザーと同期されるオフライン編集もサポートしたいと考えています。
したがって、ユーザーAは（オフラインの間に）一部のデータを変更する（つまり、データベースエントリを更新する）か、データベースに新しいレコードを追加します。ユーザーAがインターネットに接続すると、すべての変更と新しいレコードが他の共同ユーザーに配信されます。したがって、ユーザーBは変更/更新を取得し、それらをユーザーBのローカルデバイスデータベースに挿入/更新できます。
ただし、データベースエントリのIDがシステム全体で一意であることを確認する必要があります。したがって、UUIDのようなものを使用する必要があります。
私の質問：自動インクリメントされる整数の代わりにAndroid sqliteデータベーステーブルの主キーとしてUUID（String/Varchar）を使用することは悪い考えですか？
文字列（UUIDは36文字）を主キーとして使用すると、パフォーマンスの問題が発生すると思います。
整数ではなくUUIDのインデックス作成に時間がかかると思います（文字列を比較する場合と整数を比較する場合）。また、IがUUIDを使用している場合、新しいデータベースレコード/エントリが挿入されるたびに、データベースがプライマリキーカラムのインデックスを再作成する必要があると思います。これは、プライマリキーインデックスがソート順ではなくなったためです（これは、整数の自動インクリメント主キー。これは、将来のすべてのレコードが最後に追加されるためです。これは、新しい自動インクリメントされた主キーが常にこれまでで最大の数であるため、インデックスは自動的にソートされた順序になるためです。また、私がする必要があるのは、2〜3テーブルのJOINSです。また、整数ではなくJOINSの文字列を比較すると、データベースクエリの速度が低下すると思います。
しかし、そのような協調的な同期システムを実装する他の可能性を見つけることができないので、UUIDを使用する必要がありますよね？
別の可能性は、整数の自動インクリメントの主キーを使用し、2番目の列のUUIDを使用することです。したがって、ユーザーのローカルデバイスで作業するには、JOINSなどにこの主キー（整数）を使用し、他のユーザーとの同期にはuuid列を使用します。
UUIDを主キーとして直接使用することで大きな重大なパフォーマンスの問題が発生することはないと思われるので、皆さんはそのアプローチについてどう思いますか、それとも多くの仕事に対するそれはあなたの意見です。
他に何か提案はありますか？
自動インクリメントされる整数の代わりに、Android sqliteデータベーステーブル）の主キーとしてUUID（String/Varchar）を使用することは悪い考えですか？
私が考えることができる唯一の確実な問題は、そのテーブルに対するクエリの結果を表示するためにCursorAdapterとそのサブクラスを使用できないことです。 CursorAdapterには一意の整数が必要です_id列がCursorにあり、おそらくそれらの1つはありません。おそらくそれを処理するBaseAdapterを拡張して、独自のアダプターを作成する必要があります。
文字列（UUIDは36文字）を主キーとして使用すると、パフォーマンスの問題が発生すると思います。
おそらく、それがデバイスサイズのデータベースで重大な問題になったら、少し驚かれるでしょう。
しかし、そのような協調的な同期システムを実装する他の可能性を見つけることができないので、UUIDを使用する必要がありますよね？
ネットワークプロトコルには、ある種のUUIDが必要です。おそらく、データベースにそのUUIDが必要です。そのUUIDがテーブルの主キーである必要があるかどうかはわかりません。スキーマがわからないためです。
別の可能性は、整数の自動インクリメントの主キーを使用し、2番目の列のUUIDを使用することです。したがって、ユーザーのローカルデバイスで作業するには、JOINSなどにこの主キー（整数）を使用し、他のユーザーとの同期にはuuid列を使用します。
正しい。 UUID-> local integer IDマッピングテーブルがあり、ネットワークプロトコルでUUIDを使用し、ローカルデータベースをほとんどローカル整数IDを使用して保持します。これがパフォーマンスの大幅な改善になるかどうか（特にデータベーススキーマの複雑さが増す場合）は、私には言えません。
UUIDを主キーとして直接使用することで大きな重大なパフォーマンスの問題が発生することはないと思われるので、皆さんはそのアプローチについてどう思いますか、それとも多くの仕事に対するそれはあなたの意見です。
IMHO、いくつかのパフォーマンステストを実行して具体的な比較可能なデータを取得するか、データベースI/Oが遅いように思われる場合にのみそのデータを心配します。
バイナリおよびテキストとしてのUUIDのパフォーマンス結果の1つのセットは、いくぶん関連するUUID/SQLiteの質問にあります https://stackoverflow.com/a/11337522/3103448
結果によると、SQLite for CreateとQueryでは、インデックスを作成すると、バイナリUUIDと文字列UUIDの両方が効率的になります。別のトレードオフは、人間が読める文字列がバイナリファイルサイズの小さいデータサイズよりも好ましいかどうかです。