私のアプリは、他のアプリ ユーザーと同期する必要があります (自分のデバイス上で)。また、ユーザーがインターネットに接続したときに他の共同ユーザーと同期されるオフライン編集もサポートしたいと考えています。
したがって、ユーザー A は (オフライン中に) いくつかのデータを変更する (つまり、データベース エントリを更新する) か、データベースに新しいレコードを追加します。ユーザー A がインターネットに接続すると、すべての変更と新しいレコードが他の共同ユーザーに配信されます。したがって、ユーザー B は変更/更新を取得し、それらをユーザー B のローカル デバイス データベースに挿入/更新できます。
ただし、データベース エントリの ID がシステム全体で一意であることを確認する必要があります。したがって、UUID などを使用する必要があります。
私の質問: 自動インクリメントされる整数の代わりに、Android sqlite データベース テーブルの主キーとして UUID (文字列/Varchar) を使用するのは悪い考えですか?
文字列 (UUID は 36 文字) を主キーとして使用すると、パフォーマンスの問題が発生すると思います。
整数の代わりにuuidのインデックス作成に時間がかかると思います（文字列の比較と整数の比較）。また、UUIDを使用している場合、新しいデータベースレコード/エントリが挿入されるたびに、データベースは主キー列のインデックスを再作成する必要があると思います.主キーインデックスはもうソートされていないためです(これは私が使用するときです)これは、将来のすべてのレコードが最後に追加されるためです。これは、新しい自動インクリメントされた主キーが常にこれまでの最大数であるため、インデックスが自動的にソートされた順序になるためです)。私がする必要があるのは、2〜3つのテーブルを結合することです。また、整数ではなく JOINS で文字列を比較すると、データベース クエリが遅くなると思います。
しかし、このような共同同期システムを実装する他の可能性が見当たらないので、UUID を使用する必要がありますよね?
もう 1 つの可能性は、整数自動インクリメント主キーを使用し、2 番目の列 uuid を使用することです。したがって、ユーザーのローカル デバイスで作業するには、JOINS などにこの主キー (整数) を使用し、他のユーザーとの同期には uuid 列を使用します。
UUIDを主キーとして直接使用することで大きな重大なパフォーマンスの問題が発生するとは思わないので、そのアプローチについてどう思いますか、それとも多くの作業に対するあなたの意見ですか?
他の提案はありますか？