だから私は比較的単純なシステムを持っています。モバイル クライアントは、(他のモバイル クライアントと共有されている) リモート SQL サーバーに同期したい sqlite データベースにレコードを作成します。そのため、電話の sqlite テーブルに新しいレコードを作成すると、RESTful API を介してその変更をリモート サービスにプッシュします。私が抱えている問題は、データに衝突がないように主キーをどのように並べるかです(つまり、電話のレコードは、サーバー上の完全に異なるレコードと同じ主キーを持っています)。クライアント上のレコードを参照し、サーバー上の同じレコードを参照するための通常の「ベスト プラクティスは何ですか?
3 に答える
主キーにはGUIDタイプの列を使用できます。SQL ServerはタイプをサポートしますUNIQUEIDENTIFIER
SQLiteはGUID
私が知る限りそのタイプをサポートします(そうでない場合、電話のクライアントアプリはGUID値を生成する必要があります)。これにより、クライアントとサーバーで一意の値が保証されます。
GUID は適切な選択ですが、あまり意味がありません。デバイス ID + 増加する ID 値および/または時刻を送信できると便利です
そうすれば、レコードを調べることで、それがどのデバイスから来たのか、そしてそれらが発生した順序を特定できます。
アプリケーションによっては、これは非常に役立つ情報になる可能性があります。
私の好みの順序で、いくつかのオプション。これらがあなたの状況でうまくいかない場合は、コメントで明確にしてください。
自然キーを特定するか、存在しない場合は、ローカル データ属性を一意に識別する人工的なキーを作成します。here で説明されているように、人工キーはサロゲートとは異なることに注意してください。これを一意のデバイス ID とともに使用して、複合主キーを作成します
SQLite ROWID (代理キー) と一意のデバイス ID を複合主キーとして使用する
ここに記載されている潜在的な落とし穴に注意して、各行にグローバルな一意の識別子を使用してください